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1 . Introduction 

This document is a specification of the Open Shortest Path First 
{OSPF) TCP/IP internet routing protocol. OSPF is classified as an 
Interior Gateway Protocol (IGP). This means that it distributes 
information between routers belonging to a single 



The OSPF protocol is based on link-state or SPF 



by 



routing 
Autonomous 

System, 
technology . 

This is a departure from the Bellman-Ford- base used 
traditional 

TCP/IP internet routing protocols. 

The OSPF protocol was developed by the OSPF working "group 

of the 

Internet Engineering Task Force. It has been designed expressly for 
the TCP/IP internet environment, including 

explicit support for CIDR 

and the tagging of externally-derived routing 

information. OSPF 

also provides for the authentication of routing updates, and 
utilizes IP multicast when sending/receiving the updates. In 
addition, much work has been done to produce a protocol that 



responds quickly to topology changes, yet involves small amounts of 
routing protocol traffic. 



1.1. Protocol overview 

OSPF routes IP packets based solely on the destination IP 
address found in the IP packet header. IP packets are 

routed 

"as is" -- they are not encapsulated in any further 

protocol 

headers as they transit the Autonomous System. OSPF 

is a 

dynamic routing protocol. It quickly detects topological 

changes in the AS (such as router interface failures) and 

calculates new loop- free routes after a period of • 

convergence . 

This period of convergence is short and involves a minimum of 
routing traffic. 

In a link-state routing protocol, each router 

maintains a 

database describing the Autonomous System's topology. This 
database is referred to as the link-state database. Each 
participating router has an identical database. Each individual 
piece of this database is a particular router's local state 
(e.g., the router's usable interfaces and reachable neighbors). 
The router distributes its local state throughout the Autonomous 
System by flooding. 
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the 



All routers run the exact same algorithm, in parallel. From 

link-state database, each router constructs a tree of shortest 
paths with itself as root. This shortest-path tree gives the 
route to each destination in the Autonomous System. Externally 
derived routing information appears on the tree as 

leaves . 

When several equal-cost routes to a destination exist, traffic 
is distributed equally among them. The cost of a 
route is 

described by a single dimensionless metric. 

OSPF allows sets of networks to be grouped together. Such a 

grouping is called an area. The topology of an area is hidden 
from the rest of the Autonomous System. This information 

hiding 

enables a significant reduction in routing traffic. Also, 

routing within the area is determined only by the area's own 

topology, lending the area protection from bad routing data. An 
area is a generalization of an IP subnetted network. 



OSPF enables the flexible configuration of IP subnets. Each 



route distributed by OSPF has a destination, 

different sues (i.e.. di fferent masks | . This iscommnnlv 
referred Co as variable length subnetting A packet is^ h ^ 

that ° SPF Pr ° t0co1 -changes are authenticated. This means 

routina USC A d P* rti "Pate in the Autonomous System's 

fact seoarar" 6 ^ of . ^ the "tication schemes can be used; In 
each ^parate authentication schemes can be configured £or 

IP subnet. 

Externally derived routing data r e o r-o,,t-^ 1 

Exterior Gateway Protocoling as BGP^ see (^23,) " ^ " 
advertised ^ougbout the Autonomous System. 1 Tnii' externally 
link 13 kSpt se P a "te from the OSPF protocol's 

advert- fl! ta ' EaCh ext * rnal r °"te can also be tagged by the 
advertising router, enabling the passing of additional 
information between routers on the boundary of the°Autonomous 
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1.2. Definitions of commonly used terms 

specif rf 10 " Pr ° VideS ^finitions for terms that have 

referred to (Refl3J for an introduction to IP. 
Router 

calTed'a^T Internet Protocol packet switch. Formerly 
called a gateway in much of the IP literature. 

Autonomous System 

Interior Gateway Protocol 

to an ^ routing Protocol spoken by the routers belonging 

Autonomous system Abbrpv^t-^ ^ -r^r, ~ 

System has a single a ™* " Each Autonomous 

running different IGPs Se P^ate Autonomous Systems may be 



Router ID 

A 32-bit number assigned to 



each router running the OSPF 



protocol. This number uniquely identifies Che router within 
an Autonomous System.* 



Network 

In this memo, an IP network/subnet/supernet It 
is possible 

for one physical network to be assigned multiple IP 

network/ subnet numbers. We consider these to be separate 

networks. Point-to-point physical networks are an exception 

tney are considered a single network no matter how many 
them at all> IP network/subnet numbers are assigned to 

Network mask 

A 32-bit number indicating the range of IP addresses 
residing on a single IP network/subnet/supernet. This 
specification displays network masks as 
Hexadecimal numbers. 
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network is^ exan *> le < the network mask for a class C IP 

displayed as OxffffffOO. Such a mask is often displayed 
elsewhere in the literature as 255.255.255.0. 

Point-to-point networks 

A network that joins a single, pair of routers. A 56Kb 
serial line is an example of a point-to-point network. 

Broadcast networks 

t™«?h kS SU PP°" in 9 raa "y l-ora than two) attached routers, 
together with the capability' to address a single physical 
message to all of the attached routers (broadcast) 
nets N^hbo^ng routers are discovered dynamically on these 

using OSPF's Hello Protocol. The Hello Protocol itself 
takes advantage of the broadcast capability. The OSPF 
protocol makes further use of multicast capabilities, if 

assumed'to'be I^V^ ° f rOUters °« a broadcast network is 
assumed to be able to communicate directly. An ethernet is 
an example of a broadcast network. 

Non-broadcast networks 

Networks supporting many (more than two) routers but havinc 
on thes ^ " Pablli ^- Neighboring routers are Stained 
the lacker 31 " 9 K SPF ? HeU ° Protoco1 ' However, due to 

informs ion v, broadcast capability, some configuration 

information may be necessary to aid in the discovery of 
packets On non-broadcast networks, OSPF protocol 

each thaC normaUy "Nicest need to be sent to 

neighboring router. in turn. An X.25 Public Data Network 



(PDN) is an example of a non-broadcast network. 



ncop runs in one of two- modes over non-broadcast networks. 
The first mode, caLled non-broadcast multi-access or NBKA. 

simulates the operation of OSPF on a broadcast network. -The 
second mode, called Point- to-MultiPoint . treats the non- 
broadcast network as a collection of point-to-point links. 
Non-broadcast networks are referred to as NBMA networks or 
Point ~to-MultiPoint networks, depending on OSPF's mode of 
operation over the network. 
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Interface 



attached 



The 



connection between a router and one of its 



networks. An interface has state information associated 

with it, which is obtained from the underlying lower level 
protocols and the routing protocol itself. An interface to 
a network has associated with it a single IP address and 
mask (unless the network is . an unnumbered point-to-point 
network) . An interface is sometimes also referred to as a 
link. 

Neighboring routers 

Two routers that have interfaces to a common network. 

Neighbor relationships are maintained by, and usually 
dynamically discovered by, OSPF ' s Hello Protocol. 

Adjacency . 

A relationship formed between selected neighboring routers 
for the purpose of exchanging routing information. Not 

every pair of neighboring routers become adjacent. 

Link state advertisement 

Unit of data describing the local state of a router or 

network. For a router, this includes the state of the 

router's interfaces and adjacencies. Each link state 
advertisement is flooded throughout the routing domain. The 
collected link state advertisements of all routers and 
networks forms the protocol's link state database. 
Throughout this memo, link state advertisement is 
abbreviated as-LSA. 

Hello Protocol . 

The ' part of the OSPF protocol used to establish 

and maintain u 

neighbor relationships. On broadcast networks the Hello 

Protocol can also dynamically discover neighboring routers. 

Flooding 

The part of the OSPF protocol that distributes and 

synchronizes the link-state database between OSPF routers. 



Designated Router 

Each broadcast and NBMA network that has at least two 
attached routers has a Designated Router. The Designated 
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Router generates an LSA for the network and has other 

special responsibilities in the running of the protocol 

Protocol. designated Router is elected by the Hello 

The Designated Router concept enables a reduction in the 

network "quired on a broadcast or NBMA 

™^. in ^ rn "duces the amount of routing 
protocol traffic and the size of the link-state database. 

Lower-level protocols 

services^f^r^Vr" 0 ^' 30 " 53 Protocols that provide 
services to the Internet Protocol and in turn the OSPF 

leveller X^p™ ° f ^ thS X2S packet *nd frame 

ethernets ' *"* th " ethernet dat a link layer for 

1.3. Brief history of link-state routing technology 

also ° SPF " 3 link SCate r ° Uting Protocol. Such protocols are 



of 



referred to in the literature as SPF-based or distributed- 
database protocols. This section gives a brief description 

the OSPF^cocoV" link " State technology that have influenced 

£ ARP^ET^acto^switchinB 52£ ^his^rot ocol f is 

t^lZ°I£iriL d -f--~ by 
implementation of the original protocol. 

Modifications to this protocol were proposed in [Ref41 T hc .« 
modifications dealt with increasing the fault tolerance of the 
checksum^" 9 Pr ° t0C01 *™* ° th " things ^adding^ ' ^ 

to the LSAs (thereby detecting database corruption) The paper 

1 . lnC U ed means £ « reducing the routing traffic overhead ^n 
a link-state protocol. This was accomplished by introducing 
mechanisms which enabled the interval between LSA originations 
to be increased by an order of magnitude originations 
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A link-state algorithm has also been proposed for use as an 

ISO 

IS-IS routing protocol. This protocol is described in [Ref2) . 
The protocol includes methods for data and routing traffic 
reduction when operating over broadcast networks. This is 
accomplished by election of a Designated Router for each 

broadcast network, which then originates an LSA for 
the network. 



The OSPF Working Group of the IETF has extended this work in 
developing the OSPF protocol. The Designated Router concept has 
been greatly enhanced to further reduce the amount of routing 
traffic required. Multicast capabilities are utilized for 

additional routing bandwidth reduction. An area routing scheme 
has been developed enabling information 

hiding/protect ion/ reduction. Finally, the algorithms Have been 
tailored for efficient operation in TCP/IP internets. 

1.4. Organization of this document 

The first three sections of this specification give a general 
overview of the protocol's capabilities and 
functions. Sections . 

4-16 explain the protocol's mechanisms in detail. Packet 
formats, protocol constants and configuration items are 

specified in the appendices. 

Labels such as Hellolnterval encountered in the text refer to 
protocol constants. They may or may not be configurable. 
Architectural constants are summarized in Appendix B. 
Configurable constants are summarized in Appendix C. 

The detailed specification of the protocol is presented in 

terms 

of data structures. This is done in order to make the 

explanation more precise. Implementations of the protocol are 
required to support the functionality described, but need not 
use the precise data structures that appear in this 
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2. The Link-state Database: organization and calculations 

The following subsections describe the organization of OSPF's 

link- 
state database, and the routing calculations that are performed on 
the database in order to produce a router's routing table. 



2.1. Representation of routers and networks 

The Autonomous System's link-state database describes 
a directed 

graph. The vertices of the graph consist of routers and 

networks . A graph edge connects two routers when they are 
attached via a physical point-to-point network. An edge 
connecting a router to a network indicates that the router has 
an interface on the network. Networks can be either transit or 
stub networks . Transit networks are those capable of carrying 

data traffic that is neither locally originated nor locally 
destined. A transit network is represented by a graph vertex 
having both incoming and outgoing edges. A stub network's vertex 
has only incoming edges . 

The neighborhood of each network node in the graph depends on 
the network's type (point-to-point, broadcast, NBMA or Point- . 
to-Mul ti Point ) and the number of routers having an interface to 
the network. Three cases are depicted in Figure la. Rectangles 
indicate routers. Circles and oblongs indicate networks. 
Router names are prefixed with the letters RT and network names 
with the letter N. Router interface names are prefixed by the 
letter I. Lines between routers indicate point-to-point 
networks. The left side of the figure shows networks with 

their 

connected routers, with the resulting graphs shown on the right. 
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**FROM** i 

i 

t. 

| RT1 | RT2 | I 
<- + Ia + + * !• 



i,i 



|RT1|- | RT2 , T | 

•* lb. — , 0 RT2 1 X J 

* la 1 ' 3 



X 



* rb| x | 

Physical point-to-point networks 



**FROM** 

+ + * 



|RT7 j 
+- + 

[ 0 RT7| | | 



|RT7| M3 i 
T . 



N3 . * N3 1 X | , 

Stub networks 
+— + **FROM** 

l R !!i . ___|HT3|RT4|RT5|RT6| N2 | 
I X | I N2 | * RT3| 

I X- j + * RT4| || 



1 I 0 RT5| | 

Broadcast or NBMA networks 
Figure la: Network n,ap components 
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to . -e top of Figure la shQws ^ routers connected ^ ^ 

^ Point Hnk. In the resulting Unk . stace ^ ^ 

router vertices are direr M» 



assigned, they are modelled as stub lint* 

advertising a stub connection to ?u ' Wlth each route ^ 

address. Optionally, an J ^ n ° « " ut «'s interface 
to-point network. In this case K ^ assigned to the point- 

link to the IP subnet, i^t-ad J s r ° UterS adv "tise a stub 

interface addresses " ° L ° Qv ercismg each others' IP 



attach!^ " lddle ° f Fl9rUre la sh °«* a 

3 Stub ne twork). 
graph* ° f a St " b "section 



network 
In this case 



with only one 



in"thrr e 'u the network appears 
m the link-state database's 



When multiple routers are attarh-rt 

link-state database graph shows f broa dcast network, the 

connected to the network vertex This } bidi ^ctionally 
of Figure la. ertex. This is pictured at the bottom 

Each network (stub or transit) i m, 

and associated network mask The ma^"? ^ a " IP ad dress 
nodes on the network. Hosts attLES \ indicates the number of 
(referred to as host routes f an™ t° routers 

networks. The network mask for P T the 9raph as st "*> 
Oxfffff fff , which indic ££ I™ -host route is always 

presence of a single node. 



2.1.1. 



Representation of non-broadcast 



networks 



As mentioned previously oc?pf „ = „ 
networks in one of twA mS* rUn ° Ver ^-broadcast 
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protocol and flooding work 

state database. 

In NBMA mode. OSPF emulates 

network: a D esi g nated Rout * r °?^^ on f ov *r a broadcast 

-twork. and the Oesignate/ ^J"£ - S LSA for 

NB^^wo T r^^ r s a 1 de r n ?L% S r tati0 ? hl f s ° r br0ad " St and 

This representation is 



in the middle of Figure la. 



•NBMA mode is the mn^t- - 

broadcast networks Lth T* C ° ° SPF '«»- 

size and in Cerms of the amount^ 0i J ink ' s ^ database 
traffic. amount of routing 

• However, it has ,-,r,= 

°- significant restriction: it requires 

routers attached to the mrma 

communicate directly Th^ neCwork to °* able to 

xrectly. Thls restriction My be m sQnie 



non-broadcast networks, such as an ATM subnet utilizing 
SVCs . But it is often not met on other non-broadcast 
networks, such as PVC-only Frame Relay networks. On non- 
broadcast networks where not all routers can communicate 
directly you can break the non-broadcast network into 
logical subnets, with the routers on each subnet being able 
to communicate directly, and then run each separate subnet 
as an JMBMA network (see (ReflS] ) . This however requires 
quite a bit of administrative overhead, and is prone to 

misconf iguration . It is probably better to run such a non- 

broadcast network in Point- to-Multipoint mode. 

In Point-to-MultiPoint mode, OSPF treats all router-to- 
router connections over the non-broadcast network as if 

they 

were point-to-point links. No Designated Router is elected 
for the network, nor is there an LSA generated for the 

network. In fact, a vertex for the Point- to-MultiPoint 

network does not appear in the graph of the link-state 
database. 



Figure lb illustrates the link-state database representation 
of a Point- to-MultiPoint network. On the left side of the 
figure, a Point-to-MultiPoint .network is pictured. It is 
assumed that all routers can communicate directly, except 
for routers RT4 and RT5 . 13 though 16 indicate 

the routers ' » 
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IP interface addresses on the Point- to-MultiPoint network. 
In the graphical representation of the link-state database, 
routers that can communicate directly over the Point-to- 
MultiPoint network .are joined by bidirectional edges, and 
each router also has a stub connection to its own IP 
interface address (which is in contrast to the 

representation of real point-to-point links; see Figure la). 

On some non-broadcast networks, use of Point-to-MultiPoint 
mode and data-link protocols such as Inverse ARP (see 
[Refl4]) will allow autodiscovery of OSPF neighbors even 
though broadcast support is not available. 



**FROM** 

+ + + + 

| RT3 | | RT4 | | RT3 | RT4 | RT5 | RT6 | 



+ 



13 | N2 | 14 * . RT3| | X | X | X | 

+ T RT4 | X | | | X 

15 | | 16 0 RT5| X | | | X | 

+ ---+ +---■+ * RT6| X | X | X | | 



I RT5 | 



RT6 j 



13 
14 
15 
16 



IP 



Figure lb: Network map components 
Point-to-MultiPoint networks 

All routers can communicate directly over N2 exceot 
routers RT4 and rts n _u Z excepc 

ana RT5 . 13 through 16 indicate 

interface addresses 
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2-1.2. An example link-state database 

tono.cCtoo to «oot.r RTI2. »oot„ RT12 i, th.t.f.™ 

network that has been assigned interface addresses is the 
one joining Routers »Tfi „„, „ ls the 

and RT7 have "outers RT6 and RT10. Routers RT5 

set „E BGP P C ° nneCti0nS t0 ° ther Autonomous Systems. A 

routers. rOUtSS ^ &is ^y^ 'or both of these 

interface 3SS °^ ated wiCh the output side of each router 
interface. This cost is configurable by the system 
administrator. The lower the cost. the more K the 
interface is to be used to forward data traffic Costs are 
also associated with the loscs are 

externally derived routing data 

(e.g., the BGP-learned routes). 

dttDirfJ 1 ^'^ 9raph resulti "3 ^om the map in Figure 2 is 

the * correspond! 6 * rCS " re labelled with ^ cost of 
corresponding router output interface. Arcs having 

networks to 0 " rovers"" a°La v ^ *™ 

significant routers always have cost 0; they are 

extern*. 1 n °" ethel <; ss • N°ce also that h 
externally derived routing 

data appears on the graph as stubs. 

generate^bv'th 3 ' 6 d f tabase is P ie "d together from LSAs 
generated by the routers. In the associated graphical 



representation, the neighborhood of each router or transit 
network is represented in a single, separate LSA . 

Figure 4 

shows these LSAs graphically. Router RT12 has an interface 
to two broadcast networks and a SLIP line to a host. 
Network N6 is a broadcast network with three attached 
routers. The cost of all links from Network N6 to its 
attached routers is 0. Note that the LSA for Network N6 is 
actually generated by one of the network's 
attached routers: 

the router that has been elected Designated Router for 

the 

network. 



Moy 

RFC 2328 



Standards Track 
OSPF Version 2 



[Page 18] 
April 1998 



I 3+ + Ni2 N i4 

Nl|— |RT1|\ 1 \ N13 / 

I + — + \ 8\ | s/e 

\ \|/ 

/ \ 1 + + 8 8 + + 6 

* N3 * | RT4 | | RT5 | -- 

\ / + +- + + 

/ I 17 | 



N2 



3+ + / 

— |RT2|/1 



1 

+---+8 

j RT3 | 

+ + 

2 



N4 



Nil 
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13 

+ + 

|RT9| 
+ + 

|i 



N9 



|1 

+ --+ 10 + + 

I Hi I |RT12| 

+--+SLIP + *- 



I 6 
6+— + 

--|RT6| 



+ + 

la | 7 
I 



N12 

|6 2/ 
*-- — + / 
|RT7|— N15 
n— + 9 

11 

fb|5 _|_ 

1 + + 2 . | 3+ + 1 / - \ 

|RT11| | |RT10| * N6 

+ -"- + I + + \ / 



N8 



|RT8 | 
+ + 



|2 



N10 



l« 
I 

+ 

N7 
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Figure 2: A sample Autonomous System 
**FROM** 

|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT| 
-!L! 2 ll '!_! 5 16 l? ,8 ,9 l 10 l 11 l 12 |N3|N6|N8|N9| 





RT1| | 


1 1 1 


1 1 




RT2 | | 


1 1 1 


1 1 




RT3 | | 


1 1 1 


16 I 




RT4 | | 


1 i |8 


1 1 




RT5 | | 


1 |8 | 


|6 |6 




RT6 | | 


|8 | |7 


I 1 




RT7 | | 


1 1 |6 


1 1 


k 


RT8 | | 


1 1 t 


1 1 




RT9 | | 


1 1 1 


1 1 


T 


RT10| j 


1 1 1 


17 1 


0 


RTllj | 


1 1 1 




* 


RT12| j 








Nl | 3 j 


! 1 ! 


I 



N2 | 

N3 |1 

N4 | 

N6 | 
N7 j 
N8 j 

. N9 | 

N10| 

Nil | 

N12 | 

N13 I 



1 |1 

2 I 



! I 11 



I I I I 

I I I I 

I IB | |2 

I |8 \ | 



I 



I I 
I I 



1 j |1 I I 
4 I I I I 



13 |2 

1 | |1 

I I 

3 I I 



I I I 

I I I 

I I I 

I I I 



I I 



|0 |0 
I 10 



1° 

0 



j I 1° I 



I I 



I 

I N14 " I I I 18 I I I I I I | | I!, 

I N15 ' I I I I I IM I I I I I 111 

, H1 I I I I I I I I III |10| i, J i 

Figure 3: The resulting directed graph 

Networks and routers are represented by vertices 
An edge of cost X connects Vertex A to Vertex B iff 
the intersection of Column A and Row B is marked 
with an X. 
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**FROM** 
|RT9 |RT11 |RT12 |N9 | 



* RT9| | 

T RT11| | 

O RT12 | 

* N9| 



I I 

RT12's router-LSA N9 ' s network-LSA 

Figure 4: Individual link state components 

Networks and routers are represented by vertices 
An edge of cost X connects Vertex A to Vertex B iff 
the intersection of Column A and Row B is marked 
with an X. 



router in the 



2.2. The shortest-path tree 

When no OSPF areas are configured, each 

Autonomous 

f^^ m h f S an ^ den tical link-state database, leading to 
identical graphical representation. A router generates its 
shortest 9 fr ° m graph by calculating a tree of 

shortest-^ the r ° Uter itself * s -oot. Obviously, the 

- shortest e n^h e r dS °? r ° Uter d ° ing the calculation. The 

Figure 5 P * R ° Uter RT6 in ° Ur is depicted in 

host trS Hn^ VeS Path t0 any filiation network or 

in host. However, only the next hop to the destination is used 

routfrhaf^! ^T** ' f alSO that the best ro ^ e to 
router has also been calculated. For the processing 

excerna l 



of 



data, we note the next hop and distance to any router 
advertising external routes. The resulting routing table for 
Router RT6 is pictured in Table 2. Note that there is a 

separate route for each end of a numbered point-to-point network 
(in this case, the serial line between Routers RT6 and RT10) . 



appear 



Routes to networks belonging to other AS'es (such as N12) 

dashed lines on the shortest path tree in Figure 5. Use o 
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RT6 (origin) 

RT5 o o o lb 

/|\ 6 |\ 7 

8/8 | 8\ | \ 

/ | \ 6| \ 

o | o | \7 

N12 o N14 | \ 

N13 2 ( \ 

N4 o o RT3 \ 

/ \ 5 
1/ RT10 o o la 

' |\ 
RT4 o -o N3 3 | \1 

/ I | \ N6 RT7 
/ | N8 o o o 

'I II 
o RT1 



RT2 o 
/ 
/3 

/ 

N2 o o Nl 



Nil RT9 

o c 

3 



RT11 o 
I 

1| 



N9 o 
/ 

/ 

/ 



I I 2/ |9 

|RT8 / | 

o o o 

N12 N15 

4 

o N7 



RT12 

-o o o HI 

| 10 

2 



N10 



Figure 5: The SPF tree for Router RT6 

Edges that are not marked with a cost have a cost of 

of zero (these are network-to-router links). Routes 
to networks N12-N15 are external information that is 
considered in Section 2.3 
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Destination Next Hop Distance 



Nl RT3 

N2 RT3 

N3 RT3 

N4 RT3 

rb 



10 
10 
7 
8 
7 



la rtio 12 

N6 RT10 8 

N* 7 RT10 12 

N 8 RTIO io 

N9 RTIO ii 

N10 RT10 13 

N11 RTIO 14 

H l RTIO 21 



RT5 
RT7 



RT5 6 
RTIO 8 



this externally derived rouM™ 
considered in the routing information is 

next section. 

2.3. Use of external routing information 

exam^d 6 "his" ^1^™) r ° Uti " 3 is 
another routing ^rotoco! 9 °™* tion originate from 

configured (static routesT n°f ^ "* BGP " ° r be ^atically 
be included routes) . Default routes can also 

information" * uto "°"<°"s System's external routing 

throughout'the r ° UCin9 inf °™^on is flooded unaltered 

System" 5 ' ° Ur eXamPle ' a11 routers in the Autonomous 

know that Router RT7 has two external routes, with metrics 2 and 

OSPF.supports two types of external metrics. Type 1 external 
OSPF interface cost SXpreSSed ln the same units as 
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(i.e.. in terms of the link state metric). Type 2 external 
metrics are an order of magnitude larger; any Type 2 metric 

Use S of e T^eT at r the . COSt ° f P-th internal to the AS 

AS es i?Th eXCernal me trxcs assumes that routing between 
nf h% • 3 ° r C ° St o£ routin 9 a packet, and eliminates, the 

need for convers.cn of external costs to internal link state 



metrics . 



route's advertised rr»cs«- =,„/i -u external 

to the cost and che distance from Router RT6 

advertising router. When two routers are advertising the same 
providing deStl " ati °"' «™ P"*. the advertising rout" 

- extern, ,T ^ otal . cost - RT6 then sets the next hop to the 
external destination equal to the next hop that would be used 
when roucmg packets to the chosen advertising router. 

external 6 2 ' b ° th R ° Uter RT5 and RT? 3re adv <^tising 

it U f^ ^ de = tination Network N12 . Router RT7 is preferred since 
it is advertising N12 at a distance of 10 (8+2) to Router RT6 
which is better than Router RT5 ' s 14 (6 + 8). Table 3 shows the 
routes trleS addSd t0 the - uti "9 table when external 

are examined: 



Destination Next Hop . Distance 

N12 RT10 JLO ~ 

Ml 3 RT5 1 4 

N14 RT5 14 

N15 rtio 17 

Table 3 : The portion of Router RT6 ' s routing table 

listing external destinations. 

Processing of Type 2 external metrics is simpler The AS 
boundary router advertising the small es^extern^ metric is 
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router' "suooos 1655 °' ^ t0 the AS boundary 

Router RT7 PP ° SS X " ° Ur both Router RT5 and 

were advertising Type 2 external routes. Then all traffic 



Che AS 



destined for Network N12 would be forwarded to Router RT7, since 

2 < 8. When several equal-cost Type 2 routes exist the 

internal distance to the advertising routers is used f 0 ' break 
the tie . 

Both Type 1 and Type 2 external metrics can be present in 

at the same time. In that event. Type 1 external metrics always 
take precedence. 

This section has assumed that packets destined for external 
destinations are always routed through the advertising AS 
boundary router. This is not always desirable. For example 
suppose m Figure 2 there is an additional router attached to 

RTX doeT CaUed R ° Uter RTX * Su PP° se further that 

not participate in OSPF routing, but does exchange BGP 

information with the AS boundary router RT7 . Then, Router RT7 
would end up advertising OSPF external routes for all 
destinations that should be routed to RTX. An extra hop will 
sometimes be introduced if packets for these destinations need 
always be routed first to Router RT7 (the advertising router). 

To deal with this situation, the OSPF protocol allows an AS 

boundary router to specify a "forwarding address" in its AS- 

p£v ern ?i" L ^ S - In the ab ° Ve exa ™Ple. Router RT7 would specify 

RTX s IP address as the "forwarding address" for all those 
destinations whose packets should be routed directly to RTX 

The u, Mf0rWarding address " has one other application. 
It enables 

routers in the Autonomous System's interior to function as 

route servers". For example, in Figure 2 the router RT6 could 
through" r ° Ute Se ™^, gaining external routing information 
through a combination of static configuration and external 

routing protocols. RT6 would then start advertising itself 



OSPF 
the 



an AS boundary router, and would originate a collection of 

AS-external-LSAs. In each AS-external-LSA, Router RT6 would 
specify the correct Autonomous System exit point to use for 



"forwarding nati ° n thr ° Ugh ^opriate setting of the LSA's 

address" field. 
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The above discussion has been simplified by considering only 
single route to any destination. In reality, if multiple 
equal-cost routes to a destination exist, they are all 

floor7fh ed US , e6 ,- Thi5 ^^ no conceptual changes to the 

algorithm, and its discussion is postponed until we consider the 



a 



eree-building process in more detail. 

With equal cost multipath. a router potentially has several 

available next hops towards any given destination. 



Splitting the AS into Areas 
OSPF allows 



or«mfi r ^ collectl ° n s of contiguous networks and hosts to be 
grouped together. Such a group, together with the routers havina 
interfaces to any one of the included networks, is called an are! 
flaorit^ ""^k • Separate «* «=he basic link-state routing 

„ 13 meanS thaC each ar «a has its own link^state 
Action 6 C —P°" di ^ graph, as explained in the previous 



The 
area . 



Che 



traffic 



topology of an area is invisible from the outside of the 
Conversely. routers internal to a given area know nothing of 

lLk°s?"e d doi n a r„ treatin9 entirS Sys-m as a single 

^^•^s^^L.-asii^ 1 * that 

border routers, . Two routers belonging to the same area have. 

that area, identical area link-state databases. 

Routing in the Autonomous System tak<»<= „i „ 

depending on whether the sourc^d V * . ° ^vels. 

in the same area Untra-area r^f" destination of a packet reside 

(inter-area routing s used) fn'Ltrf " di " erent "eas 

packet is ' ' In mtra-area routing, the 

routed solely on information obtained within the area; no routing 

-° y Standards Track (Page 
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S^'Str.^^S ° UCS frlm C che area * — " ^ 

information. We .iscuss i^ter-areT '^^^^^ 

3.1. The backbone of the Autonomous System 

The OSPF backbone is the special OSPF Ar Pa n /nfh. 

Area 0.0.0 0 since nqpp !n. ■ {often written as 



two 



backbond HOW ^ er ' iC neSd n0t be Physically contiguous; 

confi™^^ lVUY Can be esfca blished/maintained through the 

configuration of virtual links. 9 ne 

Virtual links can be configured between any 

backbone routers y 

uttJ^Zi ^ nCerface to a c °™<°« non-backbone area. Virtual 

o^a b b y °a g v rtual th Lnk C a k s°- t th r e Pr ° t0CO1 ^ ^ 
linniimhor L- vxrcuai link as if they were connected by an 

the intra-area toJZZTlZ^S?* JELSTtS'^SL 
a P re° r^tL"' „^ y that ^ ^ "«* - "^a- 



3.2. 



Inter-area routing 



"t 6 L Uting 3 5 aCket between two non-backbone areas the 
backbone is used. The path that the packet will travel ™n h 

broken up into three contiguous pieces * 

from y Pieces. an intra-area path 

area ^■pictuSS^ 

^backbone hu°C f ^ d rati °e n ach o? the the t n n0 T US ^ yStem ' 

as eacn or the non-backbone areas 

spokes . 
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beLee°r l09Y are f as ^Tne^oooio^ ^ — 

enhanced by to P° lo 9Y of the backbone can be 

cfntror irCUal ™ S 9iV6S the S ^ Stera -^inistrator some 

control over the routes taken by inter-area traffic. 

The correct area border router to use as the D acket ^ 

source area is chosen in exactly the same way^outers * 
router^" 151 " 9 r ° UtBS a " ■ Each area border 

in an area summarizes for the area its cost to all networks 
the eXternal t0 the «««• A ^er the SPF tree is calculated for . 
^ area, routes to all inter-area destinations are calculated 

examining the summaries of the area border routers. 

3.3. Classification of routers 



basic 



copy 



Before Che introduction of areas, the only OSPF routers having 

^'j! 1 ;^ function were those advertising external routing 

information, such as Router RT5 in Figure 2. When the AS is 

spirt into OSPF areas, the routers are further divided accord no 
to function into the following four overlapping categories 9 

Internal routers 

A router with all directly connected networks belonging to 
the same area. These routers run a single copy of the 

routing algorithm. 

Area border routers 

A router that attaches to multiple areas. Area border 
routers run multiple copies of the basic algorithm, one 

for each attached area. Area 

border routers condense the 

topological information of their attached areas for 
distribution to the backbone. The backbone in turn 
distributes the information to the other areas. 

Backbone routers 

A router that has an interface to the backbone area. This 
includes all routers that interface to more than one 

not 6 " ^IL ^ 0rder K routers )- However, backbone routers do 
with all bS area - b ° rder routers. Routers 

interfaces connecting to the backbone area are supported. 
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RFC 2328 ° SPF Version 2 April 1S3Q 

AS boundary routers 

A router that exchanges routing information with routers 
belonging to other Autonomous Systems. Such a router 
advertises AS external routing information throughout the 
Autonomous System. The paths to each AS boundary router are 
known by every router in the AS. This classification is 
completely independent of the previous classifications AS 
boundary routers may be internal or area border routers and 
may or may not participate in the backbone. 

34. A sample area configuration 

Figure 6 shows a sample area configuration. The first area 

RT^r™ 3 °The e s tW ° rk d N1 ' N4 ' al ° ng WiCh thSir "tac^rrout^rs 
KT1 RT4 . The second area consists of networks N6-N8. along with 
their attached routers RT7. RT8. RT10 and RT11. The third area 
consists of networks N9-N11 and Host HI. along with their 

attached routers RT9 . RT11 and RT12. The third area has been 
configured so that networks N9-N11 and Host HI win all be 



in C e^ 9 :r r ^ t L°s ter Late; s ^3 S' ™ ^ d RT12 are 

area "outers RT3 . RT4 , RT7> rtio and. RT11 are 

- boundary°routers. Fi " ally ' " bef ° re - Route " HT5 and RT7 are AS 

. ^"fLur^^pL^irdeslr^L 1 ^- 56 ^^ *«■ 
routing. y ""criDes that area's intra-area 

the Jwo 3130 Sh ° WS the «"*'lete view of the internet for 

internal routers RT1 and RT2 It ,„ n,„ • . c 

routers. RT3 and RT4. to advertiL t 3 ° b ° f the area border 
all destinations external t^ the area 1 the . ^stances to 

Figure 7 by the dashed stub ™,?.?' »i * are lnd i<=ated in 

advertise into Area 1 the ocatil i ^ 1S °' RT3 and RT4 rausC 
RTS and RT7 . FiL « ° , ' ' " rout ^ 

are finally. AS-external-LSAs f rom RT5 ^ RT? 

flooded throughout the entire A<! • 

. Area 1. These LSAs are includ^n 1" pa f Cicula r throughout 

yield re included m Area i« s database, and 

routes to Networks N12-N15. 

Routers RT3 and RT4 must also sutnmarize ^ ^ 
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+ + 6 



N ii-ifiirr : v , 

' +—\\ . 8\ |8/8 

* N3 *— |RT4| 

\ _/ 

N2 J - - j RT2 | / 1 u , 
|RT3| | RT6 | 



N14 



— |RT5|- 
— + + + 

» . 17 , 1 



2/ 
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la 
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N4 
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N10 



In 

been 



- Area 



.Area 2 



N7 



Figure 6: A 



sample OSPF area configuration 



Area 1 (i.e.. Networks N l-L) and " etWorks «e contained in 

networks fron, the routers RT3 ' and RT4 respectively . ^^ ese 

X l^' St r £ ro a u C rers Se p L°tore h d are ETfV — *» «"« 
»X1 is a backbone r P o u L-^ S e th r t ba e C S: 



order to make the backbone connected, 
configured between Routers RIO and Rll 



a virtual 



link has 



routers RT3 . RT4 , RT7 , RT10 and RT11 



The area border 

condense nllJ 

the routing information of their atta ^^ 
dxstrxbution via the backbone^ these are thTn k^"* areas f ° r 
appear m Figure 8. Remember that the thirH *t St " bS that 

configured to condense Networks^ ^^Ind^st^ nT" 

This yields a single dashed line for networks 
Host HI i n Figure 8. Routers RT5 ^ w 

routers; their externally derived f * are AS bou ndary 

the graph in Figure 8 as stubs lnf ° rmatlon appears on 



into 
and 



Network RT3 adv. RT4 adv. 



Nl 4 4 

N2 4 4 

N3 11 

N4 2 3 

Table 4: Networks advertised to the backbone 
by Routers RT3 and RT4 . 
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"FROM* 



| RT j RT | RT | RT | RT | RT | 

|1 |2 |3 |4 |5 |7 |N3| 





RT1 




RT2 




RT3 


* 


RT4 


* 


RT5 


T 


RT7 


0 


Nl|3 


* 


N2 | 


* 


N3 1 



N4 | 
Ia,Ib| 
N6| 
N7 j 
N8 j 
N9-N11,H1 
N12 
N13 
N14 
N15 



Figure 7 : 



| 14 
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|1 
|2 
I 2D 
|I6 
j 20 
| 18 
|29| 
I I 



8 |2 

8 

8 



I I 



19 I I 



Area l's Database. 



Networks and routers are represented by vertices. 
An edge of cost X connects Vertex A to Vertex B iff 
the intersection of Column A and Row B is marked 
with an X. 
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**FROM** 



| RT | RT | RT | RT | RT | RT | RT 
|3 |4 |5 \6 |7 | 10 | 11 | 



RT3 






1 


6 


RT4 






8 




RT5 




8 
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RT6 


a 




7 




RT7 






6 




•*• 


RT10 
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RT11 






T 




Nl 


4 
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O 




N2 
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4 


* 




N3 
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1 






N4 


2 I 


3 



la | 
lb | 
N6| 
N7 j 
M8 I 
N9-N11, HI | 
N12| 
N13 j 
N14 j 
N15 | 



!8 



|7 



I 



|5 



|7 



IS 



2 I 



Figure 8: The backbone's database. 



Networks and routers are represented by vertices 
An edge of cost X connects Vertex A to Vertex B iff 
the intersection of Column A and Row B is marked 
with an X. 

Irea b border e ro n f leS ^ exchan 9 e ° f s "^^ infection between 
area border routers. Every area border router hears the area 

PicTurr 'Tf tl 1 ° th ! r - area b ° rder " Ut — " for^T 
^Picture of the distance to all networks outside of it 

ois^nc2 9 tn he c ° U ^ ted . L SAs, and adding in the backbone 
distance to each advertising router. 
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Again using Routers RT3 and RT4 



as an example, the procedure 



ba^one. This ° W g vis ^dL'," 10 " 1 " 6 the SPF tree 
routers. Al noted are the ^ff 1 "* t0 a11 °<*« area border 
and AS boundary Pouters ^ ' £7^^ J** ^ ^ 

backbone. This calculation ^7, ^ t belong to the 



Next 
routers 



s and r™"" 5 ^ SUOTnaries these area border 

outside' RT3 t be-ir R Irea an The'sTdr s\ "* ^ 
internally to the area by rt *a£ RtT" *™ advertised 

-r the ba Ck bone a = S g r^s- ^ 5» ^T™£^ 

and rt! inf ° rmatio " Sported into Area 1 by Routers RT3 

enables an internal router, such as RT1 fn 

border router intelligently Router Si^'iS ° S6 a " area 

traffic to Network NS bti r f Ti would use RT4 for 

would Network N6. RT3 for traffic to Network N10 and 







dist 


from 


dist from 






RT3 


RT4- 


to 


RT3 


* 




21 


to 


RT4 


22 


* 




to 


RT7 


20 


14 




to 


RT10 


15 


22 




to 


RT11 


18. 


25 




to 


la 


20 


27 




to 


lb 


15 


22 




to 


RT5 


14 


8 




to 


RT7 


20 


14 





e 5: Backbone distances calculated 
by Routers RT3 and RT4 . 
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Destination RT3 adv: RT4 adv. 



Ia, lb 20 
N6 16 



27 
15 

20 ig 
N8 is 18 

N9-N11,H1 29 



36 



RT5 14 8 

RT7 20 14 

Table 6: Destinations advertised into Area 1 
by Routers RT3 and RT4 . 

lpad share between the two for traffic to Network N8 . 

Router RT1 can also determine in this manner the shortest path 
to the AS - boundary routers RT5 and RT7 . Then, by looking at RT5 
and RT7's AS-external-LSAs , Router RT1 can decide between RT5 or 
RT7 when sending to a destination in another Autonomous System 
(one of the networks N12-N15) . 

Note that a failure of the line between Routers RT6 

and RT10 ^ 

will cause the backbone to become disconnected. Configuring a 
virtual link between Routers RT7 and RT10 will give 

the backbone , 

more connectivity and more resistance to such failures. 



3.5. IP subnetting support 

OSPF attaches an IP address mask to each advertised route. The 
mask indicates the range of addresses being described by the 
particular route. For example, a summary-LSA for the 

destination 128.185.0.0 with a mask of OxffffOOOO actually is 
describing a single route to the collection of destinations 
128 185 0 0 - 128.185.255.255. Similarly, host routes are 

always advertised with a. mask of Oxffffffff, indicating the 
presence of only a single destination. 
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up 



Including the mask with each advertised destination enables the 
implementation of what is commonly referred to as variable- 
length subnetting. This means that a single IP class A, B. or C 
network number can be broken up into many subnets of various 

For example, the network 128.185.0.0 could be broken 

variable-sized subnets: 15 subnets of size 4K, 15 
of size 256, and 32 subnets of size 8. Table 



their 



sizes . 

into 62 
subnets 
shows 
some of 

masks . 



the resulting network addresses 



together with 



Network address IP address mask Subnet size 



128.185.16.0 
128.185.1.0 



Oxf f ff fOOO 
Oxf fffffOO 



4K 
256 



128.185.0.8 



Oxf f£ff£f 8 



8 



Table 7: Some sample subnet 



sizes . 



B, and 



c are many possible ways Qf ^^^^ ^ a ciass a 

fQr network intQ variaMe sized subnets ^ 

doing so is beyond the scope of m • 

specification however establish*. _u J specification. This 
an IP packet is for „ « ^ ^ following guideline: When 
best -at is the best macch - o - t - p a a ^.f--^ - the network 

aescmation. Here 

match is synonymous with hhp 

For example, the default route with W SPSCific «"<*• 

destinaTi^n" — " ^ ^ b~H££" " ^ ^ 

is unambiguous . 

Attaching an address mask m 

of IP supernetting. For exal?! ™? te also cables the support 
segment could be assf^S ^ a » ln »l« Physical network SUPP ° rC 

H92.9.4.0.0x£ff«cM? se^me „ taddr ?2 s -*<askJ pair 

c network, containing ^J^^^o^W. «* 

a - - network numbers ' 192 9 d n . . 

addressing i s ^* 3-4.0 through 192.9.7.0. Such 

now becoming commonplace with ^ 

P ace with the advent of CIDR (see fkeflO),. 



class 
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In order to get beM- P r = ~ 

-ddress ranges can be ir?? at boundaries, area 

Uddre^j' ^ ^ ^ ^.t^^L 

a P ddress Many ^^J^^ ^ * *» * single 

separate subnets. Area SorSer^te^ " ^P-ed'ofLny 

contents (for distribution to * er f u then summarize the area 
single route for each address raLt*^^ by tising a 

the maximum cost to any of tL * ? . The COSt of th e route is 
specified any of the networks falling in the 



range . 



For example, an ip subnpt ., , 
b> «U OS„ „... In « -^-Jg-rf ., 

natural tp m ^^ic- t * j 

maSk - InSlde the «V number of variable 

subnets could be d fi 

d - Howeve ^ external to. the area a 



distrlbu^d -h 6ntire subnetted ""work would be 

distributed, hiding even the fact that the network is subnetted 

costs to f h C ° St ° f ChiS r ° Ut9 is the ■«*■«■ °* the set of 

costs to the component subnets. 



'3.6. Supporting stub areas 

In some Autonomous Systems, the majority of the linfc 

database may consist of AS-external-LSAs . An OSPF AS -external 
llLtt USU f V fl °° ded Ch roughout the entire AS. However OSPF 
allows certain areas to be configured as -stub areas" tl 

"SE 1 ' UH VjS n °t C ^Tf -^hroughout^tuTareas; **" 
routing to AS external destinations in these areas is based on 

ii*e" a «S > ther^ 1 ' ThiS redUCes the Unk-state database 

internal rosters 0 " ^ Cor a stub area's 

default r " "^. advanCa 9e of the OSPF stub area support. 
This is 9 mUSt bS used in the stub 

accomplished as follows. One or more of the stub area's ^ 
stub aref" r ° UterS ■ default route'tnto ST 

default ^ " ^ f ~ t — < 

ls Sit routes°will ^^J^i. ^aV^ 



area . 
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AT^ter C ^ r d e e a s C tL b atio b Lr " ~* 

exit A " arSa be c °" fi ^ed as a stub when there is a single 

P°int from the area, or when the choice of exit point need 

be made on a per-external-destination basis. For example. 



Area 



area 



(in a summary-LSA) , instead of Lh distribution inside Area 3 
Networks N12-N15 into/ throughout " the area. the AS — ter " a i'^As for 

The OSPF protocol ensures that all routers belonging to 

^aranteef tnat' confuston'wii 1^^^ ^ 

external-LSAs. ln the flo °ding of AS- 



There are a couple of restrictions on the use of stub areas 
Virtual links cannot be configured through 

stub areas. i n 

stub additi ° n ' AS boun dary routers cannot be placed internal to 



•3.7. Partitions of areas 

OSPF does not actively attempt to repair area partitions.' When 
an area becomes partitioned, each component simply becomes 

separate area. The backbone then performs routing between the 
new areas. Some destinations reachable via intra-area routing 
before the partition will now require inter-area routing. 

However, in order to maintain full routing after the partition 
an address range must not be split across multiple components of 
the area partition. Also, the backbone itself must not 
partition. If it does, parts of the Autonomous System will 
become unreachable. Backbone partitions can be repaired by 
configuring virtual links {see Section 15). 

Another way to think about area partitions is to look at the 

Autonomous System graph that was introduced in Section 2 Area 
IDs can be viewed as colors for the graph's edges . [1 J Each 



edge 
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of the graph connects to a network, or is itself a point-to- 

ii^r^ ID . in eicher case - the — is «-s»d 

A group of edges, all having the same color, and 

interconnected 

by vertices, represents an area. If the topology of the 
Autonomous System is intact, the graph will have several regions 
of color, each color being a distinct Area ID. egions 

When the AS topology changes, one of the areas may become 
partitioned. The graph of the AS will then have multiple 
regions of the same color (Area ID) . The routing in the 

rea?nnT US Continue to function as long as these 

region ' ^ COl ° r * re connected b Y the single backbone 
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4. Functional Summary 

A separate copy of OSPF's basic routing algorithm runs in each area 
Routers having interfaces to multiple areas run multiple copies of 
the algorithm. A brief summary of the routing algorithm 

follows . 

When a router starts, it first initializes the routing protocol data 
structures. The router then waits for indications from the lower- 

level protocols that its interfaces are functional. 

A router then uses the OSPF 4 s Hello Protocol to acquire neighbors 
The router sends Hello packets to its neighbors, and in turn 

receives their Hello packets. On broadcast and point-to-point 
networks, the router dynamically detects its neighboring routers by 
sending its Hello packets to the multicast address AllSPFRouters 
On non-broadcast networks, some configuration information may be 
necessary in order to discover neighbors. On broadcast and NBMA 
networks the Hello Protocol also elects a Designated 

router for the 

network. 

The router will attempt to form adjacencies with some of its 

newly 

acquired neighbors. Link-state databases are synchronized between 
pairs of adjacent routers. On broadcast and NBMA 

networks, the 

Designated Router determines which routers should become adjacent. 

Adjacencies control the distribution of routing information 

Routing updates are sent and received only on adjacencies. 

A router periodically advertises its state, which is also called 
link state. Link state is also advertised when a router's state 
changes. A router's adjacencies are reflected in the contents of 



LSAs are flooded throughout the area Th» fl™,*;„ 

reliable, ensuring that all routers ?n 5 loodln » algorithm is 

have exactly the same " 

^link-state database. This database consists of the collection 
the protocol P 66 ln tUr " yields a routin 9 table for 
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4.1. 



Inter-area routing 



3ithrn e a Vi :in g le eCti a°ref ^Porlntr 6 *h. Protocol 

other routing ° r lnt "- area routxng. no 

des f trna\ t io^ i :u^de n o e f the'are^^the 0 t0 
additional routing InL'r^i^tf:^.^^^ - ^ 
information is s Hict-in^; ^ /, area. This additional 

Systems topoLgy latl °" ° f the r6St ° f the Autonomous 



This distillation is accomplished as follows- Each 
router is by definition connected to the backbone Each 
border router summarizes the topology of its att^h J 
backbone areas for transmission 5 ^„1 h f a ^ 



border 
Each area 



h all other area ^ Z - — - 

has " An area border router then 

traffic P Ck the beSt exit rout ^ when forwarding 

inter-area destinations. 

42. AS external routes 

Systems" 0 "' 5 " th " h3Ve ^^mation regarding other Autonomous 

can flood this information throughout the AS -rh,^ 
Pa°rticL f inf ° rinatio " is ^^ributed've^ti/to^e^rr 
externai^'outing ""^ " ^ exception: ^ 

^ information is not flooded into "stub- areas (see Section 



3 



Iu V e\\\ 1 s\ Z n% e exL r rn\\ r informat inf ° rmati0 ^ P * th C ° ali «»t« 

ising external information must be known throughout the AS 



(excepting the stub areas) . For that reason, the locations of 
these AS boundary routers are summarized by the (non-stub) area 
border routers. 
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4.3. Routing protocol packets 

l^tv°«Z Pr °^° C01 r " nS direct1 ^ °ver IP, using IP protocol 89. 

OSPF does not provide any explicit fragmentation/ reassembly 
support. When fragmentation is necessary IP 

fragmentation/reassembly is used. OSPF protocol packets have 
been designed so . that large protocol packets can generally be 
split into several smaller protocol packets. This practice is 
recommended; IP fragmentation should be avoided whenever 
possible. 

Routing protocol packets should always be sent with the IP TOS 

^ho.f/r If , at 311 P° ssible - routing protocol packets 

should be given preference over regular IP 
data traffic, both 

when being sent and received. As an aid to accomplishing this 
OSPF protocol packets should have their IP precedence field set 
to the value Internetwork Control (see [RefSJ ) . 

^ All OSPF protocol packets share a common protocol header that 

described in Appendix A. The OSPF packet types are listed below 
in Table 8. Their formats are also described in Appendix A. 



Type Packet name 



Protocol functi 



Hell ° Discover/maintain neighbors 

Database Description Summarize database contents 

Link State Request Database download 

Link State Update Database update 

Link State Ack Flooding acknowledgment 



Table 8: OSPF packet types. 



OSPF -s Hello protocol uses Hello .packets to discover and"' 

Link Stat-Hf bo V el ^ionships. The Database Description and 
Link State Request packets are used in the forming of ■ 
adjacencies. OSPF's reliable update mechanism is implemented by 
the Link State Update and Link State Acknowledgment packets ^ 
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the 



of the 



LSAs 



Each Link State Update packet carries a set of new link state 
advertisements (LSAs) one hop further away from their point of 
origination. A single Link State Update packet may contain 

LSAs of 



several routers. Each LSA is tagged with the ID 

originating router and a checksum of its link state contents 
Each LSA also has a type field; the different types of OSPF 

are listed below in Table 9. 

OSPF routing packets (with the exception of Helios) are sent 
only over adjacencies. This means that all OSPF protocol 
packets travel a single IP hop, except those that are 

sent over 

virtual adjacencies. The IP source address of an OSPF 

protocol 

packet is one end of a router adjacency, and the IP destination 
address is either the other end of the adjacency or an IP 

multicast address. 



4.4. Basic implementation requirements 



An implementation of OSPF requires the following pieces 
system support: 



of 



kind, 



Timers 
Two 



example 



the 



different kind of timers are required. 



The first 



called "single shot timers-, fire once and cause a protocol 
event to be processed. The second kind, called "interval 
timers", fire at continuous intervals. These are used for 

the sending of packets at regular intervals. A good 

of this is the regular broadcast of Hello packets The 
granularity of both kinds of timers is one second. 

Interval timers should be implemented to avoid drift In 
some router implementations, packet processing can affect 
timer execution. When multiple routers are attached to a 
single network, all doing broadcasts, this can lead to the 

synchronization of routing packets (which should be 
avoided) . If timers cannot . be implemented to avoid drift 
small random amounts should- be added to/subtracted from 



interval timer at each firing. 
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LS 
type 



LSA 
name 



LSA description 



Router-LSAs 



Originated by all routers 
This LSA describes 
the collected states of the 
router's interfaces to an 
area Flooded throughout a 

single area only. 



Network -LSAs for broadc — 

and NBMA networks by 
the Designated Router. This 
LSA contains the 
list of routers connected 
to the network. Flooded 
throughout a single area only 



3,4 



routers, and flooded through- " 
out the LSA's associated 
area. Each summary-LSA 

describes a route to a 
destination outside the area 

yet still inside the AS 
(i.e., an inter-area route). 

Type 3 surranary-LSAs describe 

routes to networks. Type 4 

summary-LSAs describe 

routes to AS boundary routers. 



routers, and flooded through- 
out the AS. Each 
AS-external-LSA describes 
a route to a destination in 
another Autonomous System 
Default routes for the AS can 
also be described by 
AS-external-LSAs . 
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Table 9: OSPF link state advertisements (LSAs) 



IP multicast 



pport for receiving and sending IP 



multicast 

datagrams, along with the appropriate lower-level protocol 
support, is required. The IP multicast datagrams used by 

SIIitvT t f raVeX / [ rl e ° nS h ° p - F ° r this reason, the 

ability to forward IP multicast datagrams is not reouired. 
For xnformation on IP multicast, see fRef7] . 

Variable-length subnet support 
to " The router's IP protocol support must include the ability 

into many * """^ IP ClaSS A < B ' « C -twork number 

subnets of various sizes. This is commonly called 
variable-length subnetting; see Section 3.5 for details. 

IP supernetting support 
to The router's IP protocol support must include the ability 

aggregate contiguous collections of IP class A B anri r 
networks into larger quantities called supersets' 
Supernetting has been proposed as one way to improve the 
scaling of IP routing in the worldwide Internet For more 
information on IP supernetting, see [ReflO] . 

Lower- level protocol support 

The lower level protocols referred to here are the network 

ccess protocols, such as the Ethernet data link layer 
Indications must be passed from these protocols to OSPF 

the network interface goes up and down. For example, 

ethernet it. would be valuable to know when the ethernet 
transceiver cable becomes unplugged. 

Non-broadcast lower-level protocol support 

^^TZ^ 0 ^ 0 ^ networks < the OSPF Hello Protocol can be 
aided by providing an- indication when an attempt is made 

send a packet to a dead or non-existent router For 

example, on an X.25 PDW a dead neighboring router may be 



as 

on an 
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indicated by the reception of a X.25 clear with an 
be^ed'to otir e ^ dia *"° stic - — information would 

List manipulation primitives " " 

. ^ Much of the OSPF functionality is described in terms of 

of • operation on lists of LSAs. For example, the collection 

LSAs that will be retransmitted to an adjacent router until 
acknowledged are described as a list. Any particular Isa 



may be on many such lists. An 

OSPF implementation needs to 

be able to manipulate these lists, adding and deleting 

constituent LSAs as necessary. 

Tasking support 

Certain procedures described in this specification invoke 
other procedures. At times, these other procedures 'should 
be executed in-line, that is, before the current procedure 

S fin «hed. This xs indicated in the text by instructions 
to execute a procedure. At other times, the other 

procedures are to be executed only when the current 
procedure has finished. This is indicated by instructions 
to schedule a task. 

4.5. Optional OSPF capabilities 

The OSPF protocol defines several optional capabilities. A 
router indicates the optional capabilities that it supports in 

LSAs OSP Th HeU ° ^ CketS ' DatabaSS De --P^n Packets and i^ its 
LSAs u This enables routers supporting a mix of optional 
capabilities to coexist in a single Autonomous System. 

fpecifirarea' 165 T*^* ^^ted by all routers attached to a 
^ specific area. In this case, a router will not accept 



neighbor's Hello Packet unless there is a match in reported 

capabilities (i.e a capability mismatch prevents a neighbor 
relationship from forming) . An example of this is th, 

ExternalRoutingCapability (see below). 

Other capabilities can be negotiated during the Database 
Exchange process This is accomplished by specifying the 
optional capabilities m Database Description packets A 
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capability mismatch with a neighbor in this case will result in 
between Y * ^ °' ^ lir * st * te database being exchanged 

the two neighbors . 

The routing table build process can also be affected by the 

tn7oot*o I 6 "" "J*^*™ 1 capabilities. For example since 
the optional capabilities are reported in LSAs, routers 

:"^t e P :^::: in functions can be avoided 

beLw SPF OPt '° n ^ capabilities defined in this memo are " listed 
below. See Section A. 2 for more information. 

ExternalRoutingCapability 

Entire OSPF areas can be configured as "stubs" 
(see Section 



3.6). AS-external-LSAs will not be flooded into stub 

areas. 

This capability is represented by the E-bit in the OSPF 
Options field (see Section A. 2). In order to ensure 
consistent configuration of stub areas, all routers 

interfacing to such an area must have the E-bit 

clear in 

their Hello packets (see Sections 9.5 and 10.5). 

5 . Protocol Data Structures 

The OSPF protocol is described herein in terms of its operation 

on 

various protocol data structures. The following list comprises the 
top-level OSPF data structures. Any initialization that needs 

to be 

done is noted. OSPF areas. interfaces and neighbors also have 

associated data structures that are described later in this 
specification. 



AS. 



they 



Router ID 

A 3 2 -bit number that uniquely identifies this router in the 

One possible implementation strategy would be to use the 
smallest IP interface address belonging to the router If a 
router's OSPF Router ID is changed, the router's OSPF software 
should be restarted before the new Router ID takes effect. In 
this case the router should flush its self -originated LSAs from 
the routing domain (see Section 14.1) before restarting, or 

will persist for up to MaxAge minutes. 
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Area structures 

Each one of the areas to which the router is connected has its 
own data structure. This data structure describes the working 
of the basic OSPF algorithm. Remember that each area runs a 
separate copy of the basic OSPF algorithm. 

Backbone (area) structure 

The OSPF backbone area is responsible for the dissemination of 
mter-area routing information. 

Virtual links configured 

The virtual links configured with this router as one endpoint . 
In order to have configured virtual links, the router itself 
must be an area border router. Virtual links are 

identified by 

the Router ID of the other endpoint — which is another area 
border router. These two endpoint routers must be attached 

to a 

common area, called the virtual link's Transit area. Virtual 

links are part of the backbone, and behave as if they were 

unnumbered point-to-point networks between the two routers. A 



its T^nsit area to" intr — ™ting of 

down through PaCketS - VirtUal links ■« bought up and 

the TrLsit ldin9 are f a. ^ Sh °" e — P*<* trees for 

List of external routes 

r °"L e t ha° V e e beer tl0nS , eXternal t0 the *-onomous 
with another r:u t inrprotocor?:lr a th \ r r ^ r ° U3h experience 
configuration information or throuoh a ' ' thr ° Ugh 
(e.g.. dynamic external information to\ combination of the two 
with configured metric) h be . advertis ed *>Y OSPF 

as called an AS boundary router These 1 ^ exter " al routes 
the router into the OSPF rout!™ / r ° UteS 3re »dvertised by 

uspf routing domain via AS-external-LSAs . 

List of AS-external-LSAs 



original Iron, t j£* li » k ^* database. These have 

exte r °nai a t^ the' ^oloZuTT^ ^ t0 ^stinations 
itself an AS bLnda^^ter ToTof T* ^ ^ " 
have been self -originated f thSSe *S-«t«rnal-LSAa 
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The routing table 

routing""^ Er ° m ^ Unk - S ^te database. Each entry in the 

d^^Latio^rcls^anVrsIr^ 0 "- - d fcn °— the 
PaC, to the de S tination f A pachas ^Ttft^e 

next hop. For more information, see Section 11. 
Figure 9 shows the collection of Amt- 

typical router. The router J ^ structures present in a 

Figure ■ r ° Uter Pictured is RT10.. from the map in 

Router ^ that R ° Uter R ™ "as a virtual link configured to 

RTU, „i t h Area 2 as the link's Tr an .i, 
b V S TranSit area. This is indicated 

link^becomef ^^acj"^ 1 " 9 " ■«*« the virtual 

beeves an^inteMacr^t^e" 6 bac^ne ^ ^ ^ *' " 
interfaces depicted in Figure 9) backbone ' see the two backbone 

6. The Area Data Structure 

The area data structure contains ail the information used to run 



d«abase SPF A r ° U ^^ o ^ 90rit ^ l0 ^f ™^<* ^ own U^-s.ate 

interface belongs to a single area, and a router 

s^ngrfarea. * ™" also belongs t o a 



routed link - st * te database consists of the collection of 

ar^;^^^™:^ # ftat have originated fron, the 
area only The lilt or « f l00ded thro "9hout a single 

considered to ^^^^^^ s ^ * -so 

Area ID 

^ A 32-bit number identifying the area. The Area ID of 0.0.0.0 
reserved for the backbone. 
List of area address ranges 
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I RT10 J + 
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/ N I Routing Table | 

/ \ 

|Area JJ ♦ ' 1 Bacj^P 



J ^ ^ / \ 



/ 



(interface, ^ | Interface | ( 



to RT11 



/ \ I I ' 1 



-+ +- 



[Neighborj | Neig hbor| , ^C^"^ f^^"^ 

f + + + | + + — + 



(Neighbor RTll I 

■4 1 



links 



Figure 9: Router RT1Q . s ^ 
Associated router in t erf aces 

^rss-^'ois^-s: - «- A router 

endpo r int; J^VS"^ ^ ** «*. Router ID of its och 
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List of router-LSAs 

List of network-LSAs 
NBMA ^ 3 e„e rated for each transit broa(jc 

network in rho roaaeast and 

routers - the area . A ne tw „ rk . M ^ 

currently connect to the network. 
Lxst of summary-LSAs 

Shortest-path tree 

The shortest-path tree for th a 

Dxjkstra algorithm (see Section 16 1) netw °rk-LSAs 
TransitCapability 



TRUE 
input 



« and only if there are 

Unks usin9 che - a e s one ° T r ransi r e f a u ^r, adjacent 

- a subsequent step of ^ - used as an 

Q C / _ _ 



the area ie ^ . ' & set: to 



ExternalRoutingCapability 

Whether AS-external-LSAs will be flooded into/ throughout the 

area. This is a configurable parameter. If AS-external-LSAs 
are excluded from the area, the area is called a "stub* . 

Within 

stub areas, routing to AS external destinations will be based 
solely on a default summary route. The backbone cannot be 
configured as a stub area. Also, virtual links cannot be 

configured through stub areas. For more information, see 

Section 3.6. 
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StubDefaultCost 

If the area has been configured as a stub area, and 
the router 

itself is an area border router, then the StubDefaultCost 
indicates the cost of the default summary-LSA that the router 
should advertise into the area. See Section 12.4.3 for more 

information. 



Unless otherwise specified, the remaining sections of this 

document 

refer to the operation of the OSPF protocol within a single area. 



7. Bringing Up Adjacencies 



OSPF creates adjacencies between neighboring routers for the purpose 
of exchanging routing information. Not every two neighboring 

routers will become adjacent. This section covers the 

generalities 

involved in creating adjacencies. For further details consult 
Section 10. 



7.1. The Hello Protocol 

The Hello Protocol is responsible for establishing and 
maintaining neighbor relationships . It also ensures that 
communication between neighbors is bidirectional. ■ Hello 

packets 

are" sent periodically out all router interfaces. Bidirectional 
communication is indicated when the router sees itsel-f 

listed in 

the neighbor's Hello Packet. On broadcast and NBMA networks, 
the Hello Protocol elects a Designated Router for the network. 

The Hello Protocol works differently on broadcast networks, NBMA 
networks and Point- to-MultiPoint networks. On broadcast 
networks, each router advertises itself by periodically 
multicasting Hello Packets. This allows neighbors to be 



discovered dynamically. These Hello Packets contain the 
list r ° Uter ' S View ° f the Designated Router's identity, and the 

of routers whose Hello Packets have been seen recently. 

On NBMA networks some configuration information may be 

necessary J 

for. the operation of the Hello Protocol. Each router that may 

potentially become Designated Router has a list of all other 
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routers attached to the network. A router, having 

Designated y 

Router potential, sends Hello Packets to all other potential 

Designated Routers when its interface to the NBMA network first 

becomes operational. This is an attempt to find the 

Designated " " ' 

Router for the network. If the router itself is elected 

Designated Router, it begins sending Hello Packets to all other 
routers attached to the network. 

On Point- to-MultiPoint networks, a router sends Hello Packets to 
all neighbors with which it can communicate directly These 

such neighb ° rS may be dis covered dynamically through a protocol 

as Inverse ARP (see [Refl4] ) , or they may be configured. 

After a neighbor has been discovered, bidirectional 

communication ensured, and (if on a broadcast or NBMA network) a 
Designated. Router elected, a decision is made 

regarding whether 

or not an adjacency should be formed with the neighbor {see 
Section 10.4). If an adjacency is to be formed the 

first step ' 

is to synchronize the neighbors* link-state databases. This 
covered in the next section. 



1.2. The Synchronization of Databases 

In a link-state routing algorithm, it is very 

)rtant for all 

routers' link-state databases to stay synchronized. OSPF 
simplifies this by requiring only adjacent routers to remain 
synchronized. The synchronization process begins as soon as the 
routers attempt to bring, up the adjacency. Each- router 

describes its database by sending a sequence of Database 
Description packets to its neighbor. Each Database Description 
Packet describes a set of LSAs belonging to the router s 
database. When the neighbor sees an LSA that is more recent 

^HonlH k database C °PV< ^ makes a note that this newer LSA 

snould be requested. 



s sending .and receiving -of Database Description packets is 



called the "Database Exchange Process". During this 
process, y cms 

Each Datable r ° UterS £ °™ * " 8te/slw relationship. 

Patkets tl0n sent e hv haS * * e ™ ce nuraber - "*«=ahaa. Description 
slave ClCeCS Sent by the m "ter (polls) are acknowledged by the 

and their 911 SCh ° in9 ° f the se ^ e " c * number. Both polls 
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responses contain sundries of link state data. The master is 
the only one allowed to retransmit Database master is 

Description Packets. 

which 11 the" S ° at EiXSd inte ^l=" the length of 

configured per-interf ace constant Rxmtlnterval . 

Database When * r ° Uter haS received and sent 

Description Packets with the M-bit off. 

a U li^ g o^H^^" C J le Database Exchange Process, each router has 
date h ° Se LSAS f ° r Which the ™>i»hbor has more up-to- 

Packets eS "Link e ^ » ^"k State Request 

Packets.. Link State Request packets that are not satisfied ar ^ 
the retrans ^"ed at fixed intervals of time Rxmtlntervai ^ n 

Database Description Process has completed and all Link state 
Requests have been satisfied, the databases are deemed 
this Synchronized and the routers are marked fully adjacent. At 

time the adjacency is fully functional and is advertised in the 
two routers' router-LSAs. cuvertisea in the 

The adjacency is used by the flooding procedure as soon as the 

Database Exchange Process begins. This simplifies database 
synchronization, and guarantees thai- ; .- e aatabase 

predictable period of time ^ finishes in 



of 



7.3. The Designated Router 

De^onatefpnfr andNBtlA "^twork has a Designated Router. The 
orotoco! Performs two main functions for the routing 



The Designated Router originates a network-LSA on behalf 

the network. This LSA lists the set of routers (including 

the Designated Router itself) currently attached to the 

network. The Link State ID for this LSA (see Section^ 



12.1.4) is the IP interface address of che Designated 

using IP nStWOrk nUmber can chen °* obtained ? 9 Cy 

the network's subnet/network mask. 
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other routlrs Desi 9" ated R°""r becomes adjacent to all 

on the network. Since the link state databases are 
synchronized across adjacencies (through adjacency bring-up 
and then the flooding procedure) . the Designated Router 

Plays a central part in the synchronization process 

The Designated Router is elected by the Hello Protocol a 
router's Hello Packet contains itsRouter Priority? which is 

tL-n^^ork^ ^tnere ^ ^ ' 

that identity of the Designated Router, but ensures 

the Designated Router changes less often. See below ) 

presented in Section 9.4. 

The Designated Router is the endpoint of many adjacencies In 

packets over each adjacency. «P<*race 

Section 2 of this document discusses the directed ar.nh 

the IP addrSSS ° f their designated Router, It follows that when 
^ Designated Router changes, it appears as if the network node 

the S ne r cwo h rk S and Pla a C ri its*" "SffiLT "f" " U1 

its attached routers to originate new 



LSAs 



Designated Router. 
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7.4. The Backup Designated RouCer 

smoother.^* 'is 6 a r Backuo°Se ■ S S~ DeSi ^ ted 

aiso s ~ — - S esse eie fr each broadcast 

ES-srsrs Router - when a - S- -^:^ 
£ rrl r - *™r- ^ e 

not 9 lme ' Duri "3 this time, the network would 

oov?i a e S la tn: SLir&j^: traffic ,- The "-w- 

they already ^ CheSe adjacencies, since 

Llts'only as h L S nns S it h taL e s ri to SLfd""^ *» '""^ 
announce the new Designated Router, ^ LSAS ( " hich 

the n e two^ De 1?ri C d d Tr t :„ e d ^ »?'—•»*• a network-DSA for 
Router would be 1„ f ' ^ transition to a new Designated 
between even faster. However, this is a tradeoff 

Debated Rout^aLa^Lrs', ^ °' « when the 

Pro e toco C l UP Ea e c S h 9na H: d lo°^ e k t\ ^ eX ~ t - d * the 
Backup Designed ^^^h^r^ that — ^ 

Routerplays'a^ss^'vfrofe 00 !^? ^ 0 ^"' the B ^ ""Wed 
more of the work Thi^' ^ thS Desi 9"*ted Router do 

routing ThiS cuts down ° n the amount of local 

traffic. See Section 13.3 for more information. 
7.5. The graph of adjacencies 

Tn co d ^on nC ^f% wo ^ d ers° EL™™*^* ^ tW ° «"«=•« »*- 
they may have -ul^^-S^ be^ween^ ^ *» ~ 
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as One can picCure the collection Qf adjacencies ^ & 

within S™*^^^^'* - —s. 

graph of adjacencies describes the fl ow * " re ad 3 acent - The 
packets, and in particular Link q?\ ° routin 9 Protocol 
the Autonomous System State " pdaCe Packets, through 

^ut^L^el^t^rror^e^T °" « °-ignated 

networks. Point to-MultiPoint net' ^ PhySiCal ^-to-point 
neighboring routers l l ^* a " d vi "ual links, 
communicate directlv ° ad3acent whenever they can 
networks o^ly the DesionatfSTT' 0 " br ° adcas t and NBMA 
Router become adjacent^o atl^r ^ the Back " P ^-S^ed 
network. 11 ° ther routers attached to the 



+ 



|RT1| | RT2| 
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Figure 10: The graph of adjacencies 
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These graphs are shown in Figure 10 rt- 4 ' 
Backup «" -sign^YLter. rSr^ ST* 

Chan the Designated Router (see Section^ 6 f }° od ^ Procedure 



the 



is the 

reason for the dashed lines connecting the Backup Designated 
Router RT3 . 

8. Protocol Packet Processing 

This section discusses the general processing of OSPF routing 
protocol packets. It is very important that the router link-state 
databases remain synchronized. For this reason, routing protocol 
packets should get preferential treatment over ordinary data 
packets, both in sending and receiving. 

Routing protocol packets are sent along adjacencies only (with 

exception of Hello packets, which are used to discover the 

adjacencies) . This means that all routing 
protocol packets travel a 

single IP hop, except those sent over virtual links. 

All routing protocol packets begin with a standard 

header . The 

sections below provide details on how to fill in and verify this 
standard header. Then, for each packet type, the section giving 

more details on that particular packet type's processing 
is listed. 

8.1. Sending protocol packets 

When a router sends a routing protocol packet, it fills in the 

fields of the standard OSPF packet header as follows. For more 
details on the header format consult Section A. 3.1: 

Version # 

Set to 2, the version number of the protocol as 

documented 

in this specification. 



Packet type 
or Hello 



The type of OSPF packet, such as Link state Update 



Packet . 
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Packet length 

The length of the entire OSPF packet in bytes, including 

the 

standard OSPF packet header. 
Router ID 

the The identity of the router itself (who is originating 

packet) . 



Area ID 

The OSPF area that the packet is being sent into. 

Checksum 

The standard IP 16-bit one's complement checksum of the 

entire OSPF packet, excluding the 64-bit authentication 

field. This checksum is calculated as part of the 

appropriate authentication procedure; for some. OSPF 
authentication types, the checksum calculation is omitted. 
See Section D.4 for details. 



AuType and Authentication 

Each OSPF packet exchange is authenticated. Authentication 
types are assigned by the protocol and are documented in 
Appendix D. A different authentication procedure can be 

used for each IP network/ subnet . Autype indicates the type 
of authentication procedure in use. The 64-bit 

authentication field is then for use by the chosen 
authentication procedure. This procedure should be the 

last 

called when forming the packet to be sent. See Section 

D.4 

for details. 



all 



the 



The IP destination address for the packet is selected as 
follows. On physical point-to-point networks, the IP 
destination is always set to the address AllSPFRouters . On 

other network types (including virtual links), the majority of 
OSPF packets are sent as unicasts, i.e., sent directly to the 
other end of the adjacency. In this case, the IP destination 

just the Neighbor IP address associated with the other end of 
the adjacency (see Section 10) . The only packets not sent as 

unicasts are on broadcast networks; on these networks Hello 
packets are sent to the multicast destination AllSPFRouters, 

Designated Router and its Backup send both Link State Update 
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Packets and Link State Acknowledgment Packets to the multicast 

address AllSPFRouters, while all other routers send both their 

Link State Update and Link State Acknowledgment Packets to the 

multicast address AllDRouters. 

Retransmissions of Link State Update packets are 

ALWAYS sent 

directly to the neighbor. On multi-access networks, this means 
that retransmissions should be sent to the neighbor's IP 
address. 



The IP source address should be set to the IP address of the 

sending interface. Interfaces to unnumbered point-to-point 



networks have no associated IP address. On these interfaces 
the IP source should be set to any of the other IP addresses 
belonging to the router. For this reason, there must be at 
least one IP address assigned to the router. (2] Note that,- for 
most purposes, virtual links act precisely the same as " ' 
unnumbered point-to-point networks. However, each virtual link 
does have an IP interface address (discovered during the routing 
table build process) which is used as the IP source when sending 
packets over the virtual link. 

For more information on the format of specific OSPF packet 
types, consult the sections listed in Table 10. 



Type Packet name detailed section (transmit) 

1 Hello Section 3~5 " 

2 Database description Section 10.8 

3 Link state request Section 10.9 

4 Link state update Section 13.3 

5 Link state ack Section 13.5 

Table 10: Sections describing OSPF protocol packet transmission. 
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8.2. Receiving protocol packets 

Whenever a protocol packet is received by the router it is 
marked with the interface it was received on. For routers that 
have virtual links configured, it may not be immediately obvious 
which interface to associate the packet with. For example, 
consider the Router RT11 depicted in Figure 6 If 
RT11 receives 

an OSPF protocol packet on its interface to Network 

N8, it may 

want to associate the packet with the interface to 

Area 2 , or 

with the virtual link to Router RT10 (which is part of the 

backbone) . In the following, we assume that the packet. is 
initially associated with the non-virtual link. (3] 

In order for the packet to be accepted at the IP level it 

must 

pass a number of tests, even before the packet is passed to OSPF 
for processing: 



o The IP checksum must be correct. 



address ^ P3CkeC ' S " ^nation address must be 

o The rp protocol specified must be OSPF (89) 

Crated. 3 * ™ 1Clcast P-ck* that th . rouCer ^self 

speci^f' ° SPF PaCket header is verified. The fields 

rn t erfacr de if m "^ y ^ C L t th0 ^e C ° nfl3Ur : d *" ^ 

tney do not. the packet should be discarded: 

2 o The version number field must specify protQcol 

if o The Area ID found in the OSPF header must be verified. 

d^carded" 6 The^a^s" • f ? ^ • P "*- t Sh °» ld b « 

6 Area 10 specified in the header must either: 
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'ka'tk? "~ ~ - slstst- rn this 

~ - ivS" inte^e- ^ 

address to the ^ " m ? arin 9 the Packet's IP source 

botS addresses with thf 'f'l " address ' ««ter masking 

assigned at an. MSX9ned ^P-^ntly. if they are 

has (2) Indicate the backbone. I„ chis case. ' the packet 

been sent over a virt-n*] i; n i, 

must be an area h S ^ receiving router 

specified in the Packet a " d the Router ID 

other end of . th L^^^n i T '"'t^ ^ 
interface must also attach to the virtual link' 

succeed, the packet is accepted and i from „ 

associated with the vir , Ual ^ £j ^ 'backbone °" 

° ac a c C e k p e t :d W if Se the^atTol 0 ^ 3 ^ould only be 

tne state of the receiving interface is DR or 



Backup (see Section 9.1). 



header (which, 



spe-i'i-d U, ^ e rh S r Cified in - ChS P3Cket muSC raatch the AuType 
spe^iiicd tor che associated area. 

The packet must be authenticated. The authentication 

A^ C ^ Ure n^ S by the setCi «9 ot AuType (see 

Appendix D) . The authentication procedure may use one or 

interfa h ati ° n t teyS ' Which can be configured on .pr- 
inter face basxs. The authentication procedure may also 
verify the checksum field in the OSPF packet 



procedure fails, the packet should be discarded 
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processed^ ^ ^ * sh °" ld be further 

by the Hello Protocol (see Section 10 51 All 

point-to-point recervrng interface connects to 

RoureflO .s^e^, *J "und^ ^ * ^ 

active neighbor are discarded. 

At this point all received protocol packets are associated 

an active neighbor. For the further input processino of 
specific packet types, consult the sections U^in^able 11. 

Type Packet name detailed section (receive) 

\ Hello Section 10.5 ~ 

^ Database description Section 10.6 

Link state request Section 10.7 

* Link state update 



upoace Section 13 

Table 11: 



Link state ack Section 13.7 

Sections describing OSPF protocol packet reception. 



9 - The Interface Data Structure 

ne t „o" k ° SPF lnterf 13 the connection between a router and . 

^nougTsupportrn^ 
i-Le network is 

S B ^SSci n .2SSit X " EaCh intSrfaCe Str — e h " ■«= —t one 



single 
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An OSPF interface can be consider^ k n 

contains the attached network An * ^ l0n9 t0 the area that 
originated by the router over'rti. J ro "tmg protocol packets 

interface's Area ID On™ - interface are labelled with the 
over an interface* ^ router's LSAs" "refLcf*^ 3 
interfaces and their associated adjacencies " ^ ° f itS 

interface. ^11°^ ^ itemS * re associated with an 

atta t chernttw r ork ; t s h : c S h ^ i^V^ ** 
connected to the network Sa ™ e f ° r ali routers 

Type 
State 

deterJnes^whecner 1 ^ ° f » ^^rface. state 

State 0t i s fU ai so ad ^rec t e e d ^^^^ ^ —face. 
IP interface address 

^ g s^^^r-fari'rout 6 inter£a "- — « 

over this interface Interfaces ^ PrDt ° Co1 P acke ^ originated 
networks do not *^" t ^JZ i %Sl?S^ t -«'-*° i ** 
IP interface mask 
Che Sortio"^"^ ^ " ^ SUb " et mask - <=hi. indicates 

network" i^^nSterfici^" '~ ^ 

mask yields the IP netwnr-t k address with the IP interface 
Point-to-point^etwo'rkrrnfy-^^ ^ *"^ ed On 

ac of the link -e.es .^.^ 



all. 



Area ID 

The Area ID of the area to which the attached network belongs. 
All routing protocol packets originating from the interface are 
labelled with this Area ID. 
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Hellolnterval 

The length of time, in seconds, between the Hello packets 

that 

the router sends on the interface. Advertised in 
Hello packets 

sent out this interface. 

RouterDeadlnterval 

The number of seconds before the router's neighbors will declare 
it down, when they stop hearing the router's Hello Packets. 

Advertised in Hello packets sent out this interface. 

InfTransDelay 

The estimated number of seconds it takes to transmit a Link 

State Update Packet over this interface. LSAs contained in the 
Link State Update packet will have their age incremented by this 
amount before transmission. This value should take into account 
transmission and propagation delays ; it must 
be greater than 
zero . 

Router Priority 

An 8-bit unsigned integer. When two routers attached to a 
network both attempt to become Designated Router, the one 

with 

the highest Router Priority takes precedence. A router whose 
Router Priority is set to 0 is ineligible to become Designated 
Router on the attached network. Advertised in Hello packets 

sent out this interface. 

Hello Timer 

An interval timer that causes the interface to send a Hello 
packet. This timer fires every Hellolnterval seconds. Note 

that on non-broadcast networks a separate Hello packet is 

sent 

to each qualified neighbor. 

Wait Timer 

A single shot timer that causes the interface to exit the 

Waiting state, and as a consequence select a 

Designated Router 

on the network. The length of the timer is RouterDeadlnterval 
seconds . 

List of neighboring routers 

The other routers attached to this network. This list is formed 
by the Hello Protocol. Adjacencies will be formed to some of 
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these neighbors. The set of adjacent neighbors can be 
determined by an examination of all of the neighbors" states. 

Designated Router 

The Designated Router selected for the attached network. The 
Designated Router is selected on all broadcast and 
NBMA networks 

by the Hello Protocol. Two pieces of identification are kept 
for the Designated Router: its Router ID and its IP interface 

address on the network. The Designated Router advertises 

link 

state for the network; this network-LSA is labelled with the 
Designated Router's IP address. The Designated Router is 

initialized to 0.0.0.0, which indicates the lack of a Designated 
Router . 

Backup Designated Router 

The Backup Designated Router is also selected on all broadcast 

and NBMA networks by the Hello Protocol- All routers on the 
attached network become adjacent to both the Designated Router 
and the Backup Designated Router. The Backup Designated 

Router 

becomes Designated Router when the current Designated Router 

fails. The Backup Designated Router is initialized to 

0.0.0.0, 

indicating the lack of a Backup Designated Router. 

Interface output cost(s) 

The cost of sending a data packet on the interface, expressed in 
the link state metric. This is advertised as the link cost 

for 

this interface in the router-LSA. The cost of an interface must 
be greater than zero. 

Rxmt Interval 

The number of seconds between LSA retransmissions, for 
adjacencies belonging to this interface. Also used when 
retransmitting Database Description and Link State Request 
Packets. 

AuType 

The type of authentication used on the 

attached network/ subnet . 

Authentication types are defined in Appendix D. All OSPF_packet 
exchanges are authenticated. Different authentication schemes . 
may be used on different networks/subnets. 
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Authentication key 

This configured data allows the authentication procedure to 
generate and/or verify OSPF protocol packets. Th f° Cedure to 
Authentication key can be configured on a per-inter f ace b. sie 
For example, if the AuType indicates simple Password the 
Authentication key would be a 64-bit clear password which is 
IZr, t T° ° SPF PaCkSt header " " instead Auty^e 

key if r s ha^d 09raPhiC , a ^ he ? tiCati0n ' then the Authentication 
Key is a shared secret which enables the generation/verification 

oLZt^L *r StS WhiCh a PP e "ded to the OSPF protocol 

sTmn^ Whe \ Cr yP to 9"Phic authentication is used multiple 
simultaneous keys are suooorteri ^ _ i . pie 

transition (see Section D.3) . -chxeve smooth key 

9.1. Interface states 

The various states that router interfaces may attain is 
documented in this section. The states are listed in order of 
progressing functionality For bvs^i. %k • order of 

is lisred first followed byTlist oT^eaLtTstac^ ^ 
before the final, fully functional state is achieved The 

rel^e'n^s^^cr^L"-^ 0 ' e ^ ""--^making 

references such as "those interfaces in state areater- fh.n v- 
Figure 1! shows the graph of interface state cnlngef ^he arcs 
of the graph are labelled with the event causing the state 
t ^ change. These events are documented in Section 9.2. 

Section"'"^" SC3te maCt,ine iS Scribed in more detail i„ 

9.3 . 



Down 



This is the initial interface state. In this state the 

lower- level protocols have indicated that the interface 'is 
unusable. N o protocol traffic at all will be sent or 
received on such a interface. In this state, interface 
parameters should be set to their initial values Ail 

interface timers should be disabled, and there should be no 
ad 3 acencies associated with the interface. 

Loopback 

In this state, the router's interface to the network is 
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+ ----+ Unlooplnd + + 

| Down | < | Loopback I 

+ 



(interfaceUp 

* + I ' ♦ + 

| Waiting | <- + >| Point-to-point | 

♦— ™ — ♦ + 

WaitTimer | BackupSeen 

l 

I NeighborChange 

+ + >+ . +< + + [ 

Neighbor | | 
Change ^ | (Neighbor 
| Change 
+--+ 

> |DR| 

+ -- + 



! 



Figure 11: Interface State changes 

In addition to the state transitions pictured 
tllTr r Inte ^^ ce D ow n always forces Down State, and 
Event Looplnd always forces Loopback State 

data traffic. However, it may still be desirable to gain 

IP packet's may ^ Por this reas °"' 

still be addressed to an interface in Loopback state. To 
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LSA^^- ^"i SUCh inC «faces «e advertised in router- 
intLfacra^ess 03 ^ 0 " 65 ' ^ * ^IP 

Waiting 

In this state, the router is trying to determine the 
identity of the (Bacfcup) Designated Router the network 

To do this. the router monitors the Hello Packets it 
receives The router is not allowed to elect to k 
Designated Router nor a Designated Router until it 

Ses^r .Bac^upr^gna-ref^ter™ 15 P ~ — 



Point-to-point 



form 



functions 



eith»r S rf aCS ' ^ he . int "^" is operational, and connects 
virtual Physxcal point-to-point network or to 

link, upon entering this state, the router attempts to 

flJ^t^ With the nei 9"t>°ring router. Hello Packets are 
sent to the neighbor every Hellolnterval seconds 

DR Other 

EST ™*'^ ™' £ 5T.TS2-- 

Backup 

%l i9na r o £ir^l n P H 6Se " Router 0 ": llV* 

attached to rSf ^ 2* adjacencie s to all other routers 
pe"™ slight^ Tftlrtt ^ ^0^^ ^ 

section 7.4 for more details on the 



performed by the Backup Designated Router 



DR In this 
on 
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network- 



originate a network-LSA for the network node. The 



9.2. 



Events causing interface state changes 



label definitions are listed below Fnr * hIh! V/ , e 



InterfaceUp 

Lower-level . protocols have indicated that t-h„ „»- 
interface is operational. This enaoles the interface'to 
transition out of Down state. On virtual links the 
xnterface operational indication is actually a result of the 



shortest path calculation (see Section 16.7). 



Wai tTimer 

The Wait Timer has fired, indicating the end of 

the waiting 

period that is required before electing a (Backup) 
Designated Router. 

BackupSeen 

The router has detected the existence or non-existence of 

a 

Backup Designated Router for the network. This is done in 
one of two ways. First, an Hello Packet may be received 

from a neighbor claiming to be itself the Backup 

Designated 

Router. Alternatively, an Hello Packet may be received from 
a neighbor claiming to be itself the Designated Router, and 
indicating that there is no Backup Designated Router. In 

either case there must be bidirectional communication with 
the neighbor, i.e., the router must also appear in the 

neighbor's Hello Packet. This event signals an end to the 

Waiting state. 
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NeighborChange , 

There has been a change in the set of bidirectional 
neighbors associated with the interface. The (Backup) 
Designated Router needs to be recalculated. The following 
neighbor changes lead to the NeighborChange event. For an 

explanation of neighbor states, see Section 10.1. 

. o Bidirectional communication has been established to a 

neighbor. In other words, the state of the neighbor has 
transitioned to . 2 -Way or higher. 

o There is no longer bidirectional communication with a 

neighbor. In other words, the state of the neighbor has 
transitioned to Init or lower. 

o One of the bidirectional neighbors is newly declaring 
itself as either Designated Router or Backup Designated 
Router. This is detected through examination of that 

neighbor's Hello Packets. 

o One of the bidirectional neighbors is no longer 

declaring itself as Designated Router, or is no longer 
declaring itself as Backup Designated Router. This is 
again detected through examination of that neighbor's 
Hello Packets. 

o The advertised Router Priority for a bidirectional 
neighbor has changed. This, is again detected through 
examination of that neighbor's Hello Packets. 



Looplnd 

sssusr — * ' »™»r tte .ir-r 



Unlooplnd 



as with the Looplnd event, this 
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indication can be received hh^ 

from the lower level protocols network management or 

In t erf aceDown 

■ K«^ tio s?^ s JS^.fs this interface is » 

state is. the new interface" ^U^r *~ 
9-3. The Interface state machine 

Pt current^ 
below is organized by current inter L""' ^ ""^ ■"**«• 
event. Each ent ^ interface state and received 

resulting ln the "ate machine describes the 

J interface state and the reguired set of additional actions. 

oSina-te a ^^^^^ 
£or Some of the required acfcions beiow invQive ^ 

the neighbor state machine. For ex amn ,» u 

becomes inoperative all nef„h£ P * " he " m interface 

the interface must be destroveo" ^ COnnecti °ns associated with 

neighbor state machine, see S^tion w"^^ inforraati °n on the 

State(s): Down 

Event: InterfaceUp 
New state: Depends upon action routine 

If the attached network i. r r S ° Ut the interface, 
network. Point-to-SK,^ ^^^^^ 



Action : 



link, the interface state transitions to Point-to- 
Point. Else, if the router is not eligible to 

become Designated Router the interface state 
transitions to DR Other. 
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Otherwise, the attached network is a broadcast or 
NBMA network and the router is eligible to become 

Designated Router. In this case, in an attempt to 

discover the attached network's Designated Router 
the interface state is set to Waiting and the 



single 



shot Wait Timer is started. Additionally, if the 

network is an NBMA network examine the configured 
list of neighbors for this interface and generate 

i , ■ ne ^ hbor event st *rt for each neighbor that is 

also eligible to become Designated Router. 

State(s) : Waiting 

Event: BackupSeen 

New state: Depends upon action routine. 

Action: Calculate the attached network's Backup Designated 
Router and Designated Router, as shown in Section 
9^4 As a result of this calculation, the new state 
of the interface will be either DR Other. Backup or 



State (s): Waiting 

Event: WaitTimer 

New state: Depends upon action routine. 

Action: Calculate the attached network's Backup Designated 
Router and Designated Router, as shown in Section 
9 4. As a result of this calculation, the new state 
of the interface will be either DR Other, Backup or 

State (s): DR Other, Backup or DR 
Event : NeighborChange 
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New state: Depends upon action routine. 



Action : 



• i a " a <=hed network's Backup Designated 

Router and Desxgnated Router, as shown in Section 
9^4. As a result of this calculation, the new state 
of the interface will be either DR Other. Backup or 



State(s) : Any State 
Event: Inter faceDown 
New state: Down 

Action: t ^rs dl ^ b e L f r ss^is are Si and int — 

associated with the interface arTS^S^yS^r" 
is done by generating the event KillNbr on all 
associated neighbors ( see Section 10.2). 

State (s J : Any State 
Event : Looplnd 
New state: Loopback 

Action: Since this interface is no longer connects - 

attached network the actions associateHi th the * 
above InterfaceDown event are executed. 

State (s) : Loopback 
Event : Unlooplnd 
New state: Down 

Action: No actions are necessary. For example the 

interface variables have already been reset upon 
enterxng the Loopback state. Not e that reception of 

"° y Standards Track {Page 7<] 

° SPF V - Si °" ^ April lgg8 

an Inter faceup event is necessary before the 
interface again becomes fully functional. 

94. Electing the Designated Router 



inTtlal^ 1S t ^r°a ed ^ tot «?«« -fte machine. ' The 

a network, ^ 6 rOUter ^ the election algoritta for 

the network's Designated Router t> l. ~ . 

are Koucer and Backup Designated Router 

initialized to 0.0 0 0 Thic i nf q;. u 

Designated Houter and^ ° f • 

^l^^^^^^SS?"-,,-"--. as f oUows : 
neighbors attached to the network a^°£ *" The list ° 

bidirectional co^unicat on"uh R ouL ^' established 
list is precisplv hhl V, Router X is examined. This 

this networkr^hose^tate s ^t^ th *' S nei ^ors^o„ 

Section 10.1). Router ^ n ° r eqUal t0 2 - Wa ^ < s ^ 

to be on the "outer X itself ls also considered 

tQ Us, Discard all routers ^ ineiigiwe 

ar e e C °r n e^ibL at to ^omeoj^ having Hooter Priority of 0 
steps are then executed contfS ROU er ) The Allowing 

remain on the list? co "^derxng only those routers that 

Router'"' ^ CUrrent Values *°* . the network's Designated 

for -nd Backup Designated Router. This is used later 



comparison purposes . 



(2) 



aT^lo— fth^L °r— „ th^LV- - — 

^t^^S^ are el igible to 

routers have declared th«selv« B « v I ,° r . m0re ° f these 
(i.e.. they are current^ tlstina ^ De f lgnated *°"ter 
Designated Router, but not as themselves as Backup 

Hello Packets) the one having ° e " gnated Ro »ter. in their 
declared to be BackL Z 9 hlgi } est Hout er Priority is 

the one ta^^^SS^t!^. ch ^ °* * ^ 

routers have declared t^v^Z^^,^-^ 
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e^u S ding h \h^s^^ u h ^s 9 w h h o 3heSt h ROUt r f^*' 
. Designated Router, . and ^ u.^^^^ 

the n etwo C rk CUlat a e s the Desi ^-ed Router for 

follows. If one or more nf 

themselves Designated Router (i e " ^T" ^ declared 

to be Designated Routef . ?„ c a se°of " tle^the onV'^ 



the highest Router ID is ch n «»„ rt 

declared themselves Designated Router no routers have 

Router to be the same as rh* R ° Ute f' assign the Designated 
Router. h<? " eWly ele <=ted Backup Designated 

(4> Ba'ckurOe'signat^dTute'r^or 116 the 
if steps 2 and 3. and then proceed to step 5. For example 

the new interface state is DR T f n, 

now is UK. it the router itself is 

<S! itself L" aChe f K etW ° rk iS ™ ^ rework, and the 

Donated IT^'T^t^?^ " 
those neighbors that are f fading Hello Packets to 

Router (see Lctton n ° c e ^"e to become Designated 
invoking the ~ J,A| ' This is done by 

Priority oT^o"*" ^ ^ havin * *«out« 



router 
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<7 ' the^ 6 ^irgna^e^'Router otl'TH ° f ^ 

change. 9 Router or Backup Designated Router to 

will S6t ° f ^Jacencies associated with this interface 

need to be modified q n m^ ^ ^ 

formed, and others mf v n a ^ acen " es ma Y need to be 
this, invoke t e n Ad OK on° if ^"f^ T ° »«on„lish 
is at least 2 -Way 'thL , f " nei 9hbors "hose state 

for ay ' Tnis W1 H cause their eligibility 

adjacency to be reexamined (see Sections 10.3 and 10.4). 
de h sire ea fo°r aforderry t^t^T^T'l ^ ^ 

n.teresrs: no new ^^^^^^^^ 



Che old Backup accepts its new Designated Router 

responsibilities. 

The above procedure may elect the same router to be both 
that DeS19naCed RouCer and Ba <^up Designated Router. although 

router will never be the calculating router (Router X) itself 
The elected Designated Router may not be the router having the 
hrghest Router Priority, nor will the Backup Designated Router 

necessarily have the second highest Router Priority. if Router 

1S m C ? el£ eligible to become Designated Router it is 
possible that neither a Backup Designated Router nor I 
Designated Router will be selected in the above procedure Note 

elfoih^V V* 0 "" X 15 the ° nly cached router that Is 
eligible to become Designated Router, it will select itself as 

STST" 1 t^" d th6re ^ n ° BaCk - ^signatedUuter 

9-5. Sending Hello packets 

Hello packets are sent out each functioning router interface 

They are used to discover and maintain neighbor interface. 

Hello Packer^' 161 ^ broadcast " and networks, 

are also used to elect the Designated Router and Backup 
Designated Router. up 
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The format of an Hello packet is .detailed in Section A 3 2 The 
choo° ^ ^° ntainS the outer's Router Priority (used in 
Packet^ °T Q Ttt R ° Uter) ' the -terva/between Hello 

It.ttl i S ° Ut thS Lnterf *<=e (Hellolnterval). The Hello 

from to alS ° indlCatSS h ™ o^en a neighbor must be heard 

remain active ( RouterDeadlnterval ) . Both Hellolnterval 
RouterDeadlnterval must be the same for aU routed attached to 
a common network. The Hello packet also contains the IP address 
mask of the attached network (Network Mask) . On unnumbered 

be^set'to^^^^^ 0 ^ 5 ^ ° n VirtUal link " this field should 

The Hello packet's Options field describes the 
router's optional 

^"cacion^see SectionsT^ £%K?k 
attach^^^rea it^ ^ * " - ~» « ^ 

area"* ?£ jessing AS -ext e rnal-LSAs (i.e.. it is not a stub 

neighboring "routers E ~ blC " S6t the 

will refuse to accept the Hello Packet (see Section in 

Unrecognized bits in the Hello Packet •.s^^c^nf '""aew'should 



be 



sec to zero. 



"he Htl7 rk "I™ WMch Jackets have^ ° f r ° Ut « s ■» 

.he Hello packet also contains rhf eS " seen recently 

o e o s To ted ^^^fS^^^-Lu^ cho r - 

. selected. means that not ye * 

On broadcast networks u 

Hello packets ar,°I« t "^ e ^«l Point-to-point networks, 
multicast address AllsPFRouLr, « Nerval seconds to the i P 

end of the virtual linJri ~ 

attached neighbor everv Hon T 

— ess. - — ssrrLsrt a— - »»»° 
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9-5.1. 



ending Hello ^ ^ 

(see Sections C.5 and c fii 

attached router which is ',;„,, , 0n NBMA networks, every 

the netw pr h er — — or \ri ^ - t s^^w-^ 

neighbor^*^ 

Designated Router eli gibility 

Hello ^ interface state raust be 

Packets to be sent Waiti " 9 f ° r **» 

■ th^^^g- «f interface. Hello Packets 

router's neighbors. fometi™ Unicasts > to some subset of a 
Periodically on a timer at ? ell ° Packet is sent 

^ the router is el "hi 
-st periodically send HelL* ^uter. it 

also eligible.- In addition if " ei9hb ° rs that 

ir the router is 



itself the 

Designated Router or Backup Designated Router, it must 

also 

send periodic Hello Packets to all other neighbors This 

means that any two eligible routers are always 

excnanging 

Hello Packets, which is necessary for the correct operation 
of the Designated Router election algorithm. To minimize 
the number of Hello Packets sent, the number of 



eligible 



routers on an NBMA network should be kept small. 



If the router is not eligible to become Designated Router, 
it must periodically send Hello Packets to both the 
Designated Router and the Backup Designated Router (if they 
exist) . It must also send an Hello Packet in reply to an 
Hello Packet received from any eligible neighbor {other than 
the current Designated Router and Backup 

Designated Router) . 

This is needed to establish an initial bidirectional 

relationship with any potential Designated Router. 

When sending Hello packets periodically to any neighbor, the 
interval between Hello Packets is determined by the 
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neighbor's state. If the neighbor is in state Down, Hello 
Packets are sent every Polllnterval seconds. Otherwise 
Hello Packets are sent every Hellolnterval seconds. 

10. The Neighbor Data Structure 

An OSPF router converses with its neighboring routers Each 
separate conversation is described by a "neighbor data structure- 
Each conversation is bound to a particular OSPF router interface, 
and is identified either by the neighboring router's OSPF 

Router ID 

or by its Neighbor IP address (see below). Thus if the OSPF 

router 

and another router have multiple attached networks in 

common, 

multiple conversations ensue, each described by a unique neighbor 
data structure. Each separate conversation is loosely referred to 
in the text as being a separate "neighbor-. 

The neighbor data structure contains all information pertinent 



to 



the forming or formed adjacency between the two 

neighbors . 



An 



(However, remember that not all neighbors become adjacent.) 

adjacency can be viewed as a highly developed conversation between 
two routers. 



State 

The functional level of the neighbor conversation. This is 
described in more detail in Section 10.1. 

Inactivity Timer 

A single shot timer whose firing indicates that no Hello Packet 
has been seen from this neighbor recently. The length of the 
timer is RouterDeadlnterval seconds. 

Master/Slave 

When the two neighbors are exchanging databases, they form a 
master/slave relationship. The master sends the first 

Database 

Description Packet, and is the only part that is allowed to 
retransmit. The slave can only respond to the 

master's Database 

Description Packets. The master/slave relationship is 
negotiated in state ExStart . 
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DD Sequence Number 

The DD Sequence number of the Database Description packet that 
is currently being sent to the neighbor. 

Last received Database Description packet 

The initialized), more (M) and master(MS) bits. Options 

field, 

and DD sequence number contained in the last Database 
Description packet received from the neighbor. Used to determine 
whether the next Database Description packet received from the 

neighbor is a duplicate. 

Neighbor ID 

The OSPF Router ID of the neighboring router. The Neighbor ID 
is learned when Hello packets are received from the 
neighbor, or 

is configured if this is a virtual adjacency (see Section C.4). 

Neighbor Priority 

The Router Priority of the neighboring router. Contained in the 
neighbor 's. Hello packets, this item is used when selecting the 
Designated -Router for- the attached network. 

Neighbor IP address 

The IP address of the neighboring router's interface to the 
attached network. Used as the Destination IP address when 
protocol packets are sent as unicasts along this adjacency. 
Also used in router-LSAs as the Link ID for 

the attached network 

if the neighboring router is selected to be Designated Router 
(see Section 12.4.1). The Neighbor IP address is learned when 
Hello packets are received from the neighbor. For virtual 



10.6) 



to 



^^ S 'K th L Neighb ° r IP address is learned during the routina 
table build process (see Section 15). routing 

Neighbor Options 

Le a e rnpH tl0na ? SPF capabilities supported by the neighbor 
Learned during the Database Exchange process (see Section 

The neighbor's optional OSPF capabilities are also listed in its 

^ This enables received Hello Packets to be 

rejected (i.e.. neighbor relationships will not even start 

form) if there is a mismatch in certain crucial OSPF 

capabilities (see Section 10.5) . The optional OSPF capabilities 
are documented in Section 4.5. capaniiities 
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Neighbor's Designated Router 

The neighbor's idea of the Designated Router. If this is the 
neighbor itself, this is important in the local calculation of 
neLo^r ated R ° Uter - ° efined broScL^^and^BMA 

Neighbor's Backup Designated Router 

The neighbor's idea of the Backup Designated Router If this is 
the neighbor itself, this is important in the local calculation 
NB^ h net B :orks. DeS19nated R ° Uter - De ^^ on bro^casf ^nd 

describe " ext set ° E tables are lists of LSAs. These lists 

subsets of the area link-state database. This 
memo defines five 

^^distinct types of LSAs. all of which may be present i„ an 

su^ry^iAfuirsto^rrr'^the"" 0 ^^ 3 ' and *~ 3 «* 4 

external-LSAs' (stored^ the glo^l ^tf structur^ ' "* ^ 

Link state retransmission list 

no, li ^^ of ^ LSAs have been flooded but 

not acknowledged on 

until thiS adjacenc *- T "ese will be retransmitted at intervals 

they are acknowledged, or until the adjacency is destroyed. " 

Database summary list 

The complete list of LSAs that make up the area link-state 
database at the moment the neighbor goes into * 

-•cite base Exchange 

Description Jackets" " C ° ^ in Database 



Link state request list 

The list of LSAs that need to be received from this neighbor in 
order to synchronize the two neighbors' link-state databases. 
This list is created as Database Description packets are 
received, and is then sent to the neighbor in Link State Request 
packets. The list, is depleted as appropriate Link State Update 
packets are received. 
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10.1. Neighbor states 

The state of a neighbor (really, the state of a conversation 
being held with a neighboring router) is documented in the 
following sections. The states are listed in order of 

progressing functionality. For example, the inoperative state 

is listed first, followed by a list of intermediate states 
before the final, fully functional state is achieved. The 
specification makes use of this ordering by sometimes making 

references such as "those neighbors/adjacencies in state 

greater 

than X" . Figures 12 and 13 show the graph of neighbor state 
changes. The arcs of the graphs are labelled with the event 
causing the state change. The neighbor events are 

documented in 

Section 10.2. 

The graph in Figure 12 shows the state changes effected by the 

Hello Protocol. The Hello Protocol is responsible for neighbor 
acquisition and maintenance, and for ensuring two way 
communication between neighbors . 

The graph in Figure 13 shows the forming of an adjacency. Not 
every two neighboring routers become adjacent (see Section 
10.4) . The adjacency starts to form when the neighbor is in 

state ExStart. After the two routers discover their 
master/slave status, the state transitions to Exchange. At 

this 

point the neighbor starts to be used in the flooding 

procedure, 

and the two neighboring routers begin synchronizing 

their 

databases. When this synchronization is finished, the neighbor 
is in state Full and we say that the two routers are fully 
adjacent. At this point the adjacency is listed in LSAs. 

For a more detailed description of neighbor state changes, 

together with the additional actions involved in each change, 
see Section 10 . 3 . 



Down 

This is the initial state of a neighbor conversation. 



It 

indicates that there has been no recent 

information received 

from the neighbor. On NBMA networks, 

Hello packets may- 
still be sent to "Down" neighbors, although at a reduced 
frequency (see Section 9.5.1). 
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+ •+ 

| Down | 

+■ + 

\ 



\Start 



Hello 
Received 



> | Attempt] 



+ +<- + 

| Init | < 

+ +< 



2 -Way |l-Way 
Received | Received 



I Hel loReceived 
- + 



| ExStart | <- 



->|2-Way| 



Figure 12: Neighbor state 



changes 



(Hello Protocol) 



In addition to the state transitions pictured. 
Event KillNbr always forces Down State, 

Event InactivityTimer always forces Down State, 

Event LLDown always forces Down State 
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+ + 

I ExStart I 



NegotiationDone | 

+ + + 

| Exchange | 



effort 



Exchange | 
Done | 
| + | + + 

|Full|< + >|Loading| 

+ +<_ + + + 

| LoadingDone | 
+ _ + 

Figure 13: Neighbor state changes (Database Exchange) 

In addition to the state transitions pictured 

Event SeqNumberMismatch forces ExStart state 

Event BadLSReq forces ExStart state, 

Event 1-Way forces Init state. 

Event KillNbr always forces Down State, 

Event InactivityTimer always forces Down State, 

Event LLDown always forces Down State 

Event AdjOK? leads to adjacency formiAg/ breaking 

Attempt 

This state is only valid for neighbors attached to NBMA 

networks it indicates that no recent information hasten 
received from the neighbor, but that a more concerted 

should be made to contact the neighbor. This is done by 
sendxng the neighbor Hello packets at intervals of 
Hellolnterval (see Section 9.5.1). 



Init 



In this state an Hello packet has recently been seen from 
the neighbor. However, bidirectional communication has 

itself did e n o r, tabUShed W i tH the nei 3 hb °r (i-e., the router 
itself did not appear m the neighbor's Hello packet). All 
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Hello ■ nSighb0rS ln this st * te lor higher, are listed in the 

packets sent from the associated interface. 
2 -Way 



! 



In this state, communication between the two routers is 
bidirectional. This has been assured by the operation of 
the Hello Protocol. This is the most advanced state 

short 

of beginning adjacency establishment. The (Backup) 
Designated Router is selected from the sec of neighbors in 
state 2-Way or greater. 

ExStart 

This is the first step in creating an adjacency between the 
two neighboring routers. The goal of this step is to 

decide . . 

which router is the master, and to decide upon the initial 

DD sequence number. Neighbor conversations in 

this state or 

greater are called adjacencies. 

Exchange 

In this state the router is . describing its entire link 

state 

database by sending Database Description packets 

to the 

neighbor. Each Database Description Packet has a DD 
sequence number, and is explicitly acknowledged. Only one 
Database Description Packet is allowed outstanding at any 

one time. In this state. Link State Request Packets may 

also be sent asking for the neighbor's more recent LSAs . 

All adjacencies in Exchange state or greater are used by 

the 

flooding procedure. In fact, these adjacencies are fully 
capable of transmitting and receiving all types of OSPF 

routing protocol packets. 

Loading 

In this state. Link State Request packets are sent to the 
neighbor asking for the more recent LSAs that have been 
discovered (but not yet received) in the Exchange state. 

Full 

In this. state, the neighboring routers are fully adjacent. 
These adjacencies will now appear in router-LSAs and 
network-LSAs . 
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10.2. Events causing neighbor state changes 

State changes can be effected by a number of events. These 
events are shown in the labels of the arcs in Figures 12 and 13. 
The label definitions are as follows: 

HelloReceived 

An Hello packet has been received from the neighbor. 



Starb 



sent 



This is an indication that Hello Packets should 



be 



to the neighbor at intervals of Hellolnterval seconds This 
event is generated only for neighbors associated with NBMA 



router 



networks . 

2-WayReceived 

Bidirectional communication 
two neighboring routers. 



has been realized between the 
This is indicated by the 



seeing itself in the neighbor's Hello packet. 



NegotiationDone 

The Master/Slave relationship has been negotiated 

sequence numbers have been exchanged. This signals 
start of the sending/receiving of Database Description 
packets. For more information on the generation of 
event, consult Section 10.8. 



and DD 
the 

this 



ExchangeDone 

Both routers have successfully transmitted a full sequence 
of Database Description packets. Each router now knows what 
parts of its link state database are out of date. For more 
• information on the generation of this event, consult Section 

BadLSReq 

A Link State Request has been received for an LSA not 

Da^r'V"^ 6 database. This indicates an error in the 

Database Exchange process. 

Loading Done 

Link State Updates have been received for all out-of-date 
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portions of the database. This is indicated by the Link 
state request list becoming empty after the Database 

Exchange process has completed. 

AdjOK? 

l? e Ki Si u n ^ USt be . made as to whether an adjacency should be 
established/maintained with the neighbor. This event will 

start some adjacencies forming, and destroy others. 



of 



The following events cause well developed neighbors to revert 

when e thfn^^H UnlikG ab ° Ve eVSntS ' these events ™Y occur 

when the neighbor conversation is in any of a number 

states. 



SeqNumberMismatch 



from 



A Database Description packet has been received that either 
a) has an unexpected DD sequence number, b) unexpectedly has 
the Init bit set or c) has an Options field differing 



X.25 



the last Options field received in a Database Description 

packet. Any of these conditions indicate that some error 
nas occurred during adjacency establishment. 

1-Way 

An Hello packet has been received from the neighbor in 
which the router is not mentioned. This indicates that 
communication with the neighbor is not bidirectional. 

KillNbr 

^ iS ,, is an in <iication that all communication with the 

neighbor is now impossible, forcing the neighbor to 

revert to Down state. 

InactivityTimer 

The inactivity Timer has fired. This means that 

Hello 

packets have been seen recently from the neighbor The 
neighbor reverts to Down state. 

LLDown 

This is an indication from the lower level protocols that 
the neighbor is now unreachable. For example, on an 

network this could be indicated by an X.25 clear indication 
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with appropriate cause and diagnostic fields. This event 
forces the neighbor into Down state. 

10.3. The Neighbor state machine 

Eafh^rf ^ scri P tion ° f , th « neighbor state changes . follows . 
Each state change is invoked by a „ event (Section 10 2) This 

™ -ay Produce different effects, depending on the current 
is oroanized f° r ^is reason, the state machine below 

is organized by current neighbor state and received event. 

state L n H C ?h state ."^"i"e describes the resulting new neighbor 
state and the required set of additional actions. 

?h!V " eig !? b ° r ; s state changes, it may be necessary to rerun 
whe t he S19n ft Route V le "i°n algorithm. This is determined by 
Section 5 5, Xnt " face "eighborChange event is generated (see 

section 9.2). Also, if the Interface is in DR state (the 

is itself Designated Router), changes in neighbor state may 
cause a new network-LSA to be originated (see Section 12*1). 

When the neighbor state machine needs to invoke the 



Each 



router 



interface 



SectLr^ 1 ^'.!' ^ ^ aS a sched ^ed task (see 

that neither S1 ^ lifies thing., by ensuring 

state machine will be executed recursively. 

State (s) : Down 
Event: Start 
New state: Attempt 

Action: Send an Hello Packet to the neighbor (this neighbor 
xs always associated with an NBMA network) and start 
The timer's Inactivity Timer for the neighbor. 

the" Ei neiohh° Uld indicate communication with 

cne neighbor was not attained. 

State (s) : Attempt 
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Event: HelloReceived 
New state: Init 

Action: Restart the inactivity Timer for the neighbor, since 
the neighbor has now been heard from. 

State(s) : Down 

Event: HelloReceived 
New state: Init 

Action: Start the Inactivity Timer for the neighbor The 
timer's later firing would indicate that the 
neighbor is dead. 

State(s): Init or greater 
Event : HelloReceived 
New state: No state change. 

Action: Restart the inactivity Timer for the neighbor, since 
the neighbor has again been heard from. 



State{s): Init 



Event: 2 -WayReceived 



New state: Depends upon action routine. 

Action: Determine whether an adjacency should be established 
with the neighbor (see Section 10.4). If not, the 
new neighbor state is 2-Way. 

Otherwise (an adjacency should be established) the 
neighbor state transitions to ExStart . Upon 
entering this state, the router increments the DD 
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sequence number in the neighbor data structure. If 
this is the first time that an adjacency has been 
attempted, the DD sequence number should be assigned 
some unique value (like the time of day clock) . 

then declares itself master (sets the master/slave 

bit to master) , and starts sending Database 

Description Packets, with the initialize (I) , more 
(M) and master (MS) bits set. This Database 

Description Packet should be otherwise empty. This 
Database Description Packet should be retransmitted 

at intervals of Rxmtlnterval until the next state is 
entered (see Section 10.8). 



State (s) : ExStart 

Event : NegotiationDone 

New state: Exchange 

Action: The router must list the contents of its entire area 
link state database in the neighbor Database summary 
list. The area link. state database consists of the 
router-LSAs, network-LSAs and summary-LSAs contained 
in the area structure, along with the AS-external- 
LSAs contained in the global structure. AS- 
external-LSAs are omitted from a virtual neighbor's 
Database summary list. AS-external-LSAs are omitted 
from the- Database summary list if the area has been 
configured as a stub (see Section 3.6). LSAs whose 
.age is equal to MaxAge are instead added to - the 

neighbor's Link state retransmission list. A ~ 
summary of the Database summary list will be sent to 
the neighbor in Database Description packets. Each 

Database Description Packet has a DD sequence 

number, and is explicitly acknowledged. Only one 
Database Description Packet is allowed outstanding 

at any one time. For more detail on the sending and 
receiving of Database Description packets, see 
Sections 10.8 and 10.6. 
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State(s) : 
Event : 
New state: 
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routine. 



Action: If the neighbor Link state request list is empty 

the new neighbor state is Full. No other action 

required. This is an adjacency's final state. 

Otherwise, the new neighbor state is Loading Start 

(or continue) sending Link- State Request packets to 

tne neighbor (see Section 10 .9) . These 



requests 



for the neighbor's more recent LSAs (which 

discovered but not yet received in the Exchange 
state) . These LSAs are listed in the Link state 
request list associated with the neighbor 



State(s) 
Event 
New state 
Action 



Loading 
Loading Done 
Full 

No action required, 
state. 



This is an adjacency's final 



State(s): 2-Way 
Event: AdjOK? 
New state: Depends upon action 



routine.. 



Action: Determine whether an adjacency should be formed with 
the neighboring router 

(see Section 10.4). rf not, 

the neighbor state remains at 2-WayV Otherwise 

transition the neighbor state to ExStart and perform 
tne actions associated with the above 

state machine 

entry for state Init and event 2 -Way Received. ' 
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State(s): ExStart or greater 
- Event: AdjOK? 
New state: Depends upon action routine , 

ACti0n: st^^^- - ^ in, _ter should 

-d no further acti ^ s L nec ^ s e ^ S - s tate change 

-st^e^ 

to 2- Way . The^ink ^t^SSLS*^ 
Database summary list r ? t ^ ansmis sion list, 

cleared of^l^ St * te ~^ est 



State(s) : Exchange or greater 

Event : SeqNumber Mismatch 

New state: ExStart 

Action: The 



retra^smission^i^ 5 ^^. Jhe state 

state request list are c ?etred Tr^ U-t 
router increments the DD secroenee k" ? hen the 
neighbor data structure H^V °"»ber in the 

(sets the master™la™ hi?^ ^ ltSelf "^ter 
sending Database Descrio C io^ 0 p ma u ter) ' and Starts 
initialise (I, more m? * 2 Packets '- the 
This Database Description^ Tt^Z ,MS) "its set. 
empty (see Section"? 8? " °* enrise 



State (s): Exchange or greater 
Event: BadLSHeg 
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New state.- ExStart 
Action : 



: The action Cor event Badr qb=„ • 

for the neighbor event ^a^ 1S J XaCtly Che sa ™ " 

(possibly partially formed) SeqNura ^ erM "match. The 

reestablish^. '"L *" KST ^ 

m0re inf °'™ ti - - the neighbor state machine 



is^L^ * S . invoked whe * event SeqNumberMismatch 
generated m state Exchange or greater. 



State (s): Any state 

Event: KillNbr 

New state: Down 

sugary ^ state retransmission li st / Da taJbase 

^is^theina^^f ^ *™ ^ 

as- Also, the Inactivity Timer is disabled. 

State(s): Any state 
Event : LLDown 
New state: Down 

suncoary ACti ° n: ^ state re t ran^ssio».U,t. 

list and Link state recm^t- 1 -;.>*. 

"AS. Also . the Ina ^£ J-t-; g;™. .f 

State (s) : Any state 

Event: InactivityTimer 
New state: Down 

sundry ACCi ° n: Lin * SCaCe -transmission list. Database 

list M d Link state request list are Cleared of 



?° y Standards Track 

RFC 2328 OSPF version 2 

State(s): 2-Way or greater 

Event: 1-WayReceived 

New state: Init 



[Page 94) 
April 1998 



summary ACti0 " : ^ Link State "transmission list. Database 
LSAs. and StaCe reqUeSt lis ' are cleared of 



State(s): 2 -Way or greater 
Event: 2-WayReceived 



New state: 
Action: 



No state change. 
No action required. 



State (s) : init 

Event : l - WayRecei ved 

New state; No state change. 

Action: No action required. 

10.4. Whether to become adjacent 

Adjacencies are established with some subset of 

nexghbors. Routers connected by poi^toW« t L- rcmter * 
Point-to-MultiPoint networks anl virtual 1^2 .^ ^^ ' 
adjacent. On broadcast and NBMA networks ^1 
adjacent to both the Desirm**-!^ "ecworlcs, all routers become 
Designated Designated Router and the Backup 

Router.. 

The adjacency- forming decision- occurs in ^ i 
neighbor state machine. Pi rs " ^wo.P^es m the 

communication c ' when ^idrrectaonal 

a. 1 aas s-srs. sat --^ 
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not 



when at 



att^t* • " Che d -i«on is ^de to 

adjacency, the state of the neighbor convocation stops at 2- 

.... An . ad i acencv should be established with , 
bxdirectional neighbor ^isned with a 

least one of the following conditions holds: 
underlying network type is point-to-point 
underlying network type is Point-to-MultiPoint 
underlying network type is virtual link 
router itself is the Designated RouCer ' 
router itself is the Backup Designated Router 
neighboring router is the Designated Router 
neighboring router is the Backup Designated Router 



o 


The 


o 


The 


o 


The 


o 


The 


0 


The 


0 


The 


0 


The 



1.0.5. Receiving Hello Packets 



This section explains the detailed processing of a received 
Hello Packet. (See Section A. 3. 2 for the format of Hello 
packets . ) The generic input processing of 

OSPF packets will 

have checked the validity of the IP header and the OSPF packet 
header. Next, the values of the He t work Mask, Hellolnterval, 

and RouterDeadlnterval fields in the received Hello packet mist 
be checked against the values configured for the receiving 
interface. Any mismatch causes processing to stop and the 
packet to be dropped. In other words, the above fields are 

really describing the attached network's 

configuration. However, 

there is one exception to the above rule: on point-to-point 
networks and on virtual links, the Network Mask in the 

received 

Hello Packet should be ignored. 

The receiving interface attaches to a single OSPF area (this 
coi*ld be the backbone) . The setting o£ the B-bit found in the 
Hello Packet's Options field must match this area's 
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ExternalRoutingCapability. If AS-external-LSAs are* 
not flooded 

into/ throughout the area (i.e. .the area is a •stub*) the. E-bit 
must be clear in received Hello Packets; otherwise the E-bit 

must be set. A mismatch causes processing to stop and 



the 



packet to be dropped. The setting of the rest of the bits in 
the Hello Packet's Options field should be ignored. 



At this poxnt, an attempt is made to match the source of the 

Hello Packet to one of the receiving interface's neighbors If 
the receiving interface connects to a broadcast, Point-to- 
MultiPoint or NBMA network the source is identified by the IP 
source address found in the Hello's IP header. If the receiving 
interface connects to a point-to-point link or a virtual link, 
the source is identified by the Router ID found in the 

Hello's 

OSPF packet header. The interface's current list of neighbors 
is contained in the interface's data structure. If a 
matching - 

neighbor structure cannot be found, (i.e., this is the first 
time. the neighbor has been detected), one is created. The 
initial state of a newly created neighbor is set to Down. 

When receiving an Hello Packet from a neighbor on a broadcast 
Pomt-to-MultiPoint or NBMA network, set the neighbor 
structure's Neighbor ID equal to the Router ID found in the 
packet's OSPF header. For these network types, the neighbor 
structure's Router Priority field, Neighbor's Designated Router 



Hello Packet; changes in the^f J- ^ found « the received 
Possible use in rt^xS' 1 *^ ft*, 

point-to-point network (but not ™ » receiving an Hello on a 

neighbor structure's Neighbor ip afM °" * ■"■*> ^t the 

source address. exgnoor IP address to the packet's IP 

events^" " St ° f the Hello Packet is exa^ned. generating 

These t0 ^ t0 and 

neighbor state machine tT^iJ? i??^"* the 
state transitions may be e«ec^ed bt "» , Several neighbor 

y errected. by a single received Hello: 
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to be 



neighbor state machine should " appears » "lis list. the 
WayReceived . Otherwise tot „^ S^** 5 " ith the ev ent 2- 
be executed with^ne event i w?^ mmthin » ^ould 

of the packet stops. "WayReceived, and the processing 

° l e s C ' "no't^e^vSte field 
scheduled with the «^&g££g2 State " 

address) and the Backup^eS^TT field = »«**»>or IP 
packet is equal to 0.0 0 0 anTt^ R ° Ut ? r . fiel ° in the 
state waiting, the receivir^ 7„^!«f lvln »' ^erface- is in 
scheduled with the event LLoSeL 1 te machine is 
neighbor is declaring itself tTL ° therwi ". if the 
itseif had not previous 1^^^^^ 

Designated Router where i t- k=j • -- 

interface's state machiLf d prevXously ' the receiving 
NeighborChange. hl " e 13 sc heduled with the event 

° If the neighbor is declarino i f „u 

Router (Hello Packet's Backuo nlliL^ ° Bacltup D «ignated 
Neighbor IP address) and th Desi9na ted Router field = " 
state oaress) and the receiving interface is in 

Waiting, the receivina i„i-„ r f,„ . 

scheduled with the event b^v c S stat e machine is 
neighbor is declaring itseS^oT ^J™**' " . the 

3 itself to be Backup Designated Router 



declaring ^ ** »** vi -<™*Y- or the neighbor is not 

event NeighborChange . 

in response. See back to the neighbor 

Section 9.5.1 for more details. 
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10.6. Receiving Database Description Packets 

ne ighfc < > r 0 rt a te Sh0Uld ^ *~ — • "P™ the 

Pfcketiteic: £SKi~5?£ ^t^' ^ 
structure under -last «dvrf ^hTT'^'*. 

S C ionf et -%iSdf^rDD^ SE^sai 

set ' ana uu sequence nuober. If these fields are 

rec^ved'f^^h:^:-^^^^ 56 ""^ion packets 

packet is considL^d^o^e'a'-duplioate^n^f 
described below. P ate xn the Processing 

^tes^r Tt"r^ s^^^f 6 ^ esc ription packet 
accept on the'receWin^t^rrLe^hou ^Lent" t ^ "V* 

°tate i L cion packet is SSS: the 



the 



Down 

The packet should be rejected. 

Attempt 

The packet should be rejected. 

Init 

The 



event ^ nei ^^ state machine should be executed with the 

SxStart, the processing of the currenrpac^t^ouirthen" 6 * 



Srt e beW thiS n6W State W falling through to case 
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2-Way 

DescriptiorPac k etr Cket Sh ° Uld bC i9n ° red - ^abase 
adjacencies"?) ° nly f ° r th * of bringing up 

ExStart 

chen h che e n e ig^ cases, 
event NegotiationDone Teasing the'stfte'tn 01 ^ ^ the 

packet shoufd be acc^S as neif^ the 
o The initialize,!,, Mre ^ «, t . r|IBI , bits are 

o ^initialized) and master <MS) bits are off .-h- 

acknowledgment) and the nli^kl 7 n 

is smaller . neighbor's Router ID 

than the router's own in hhic 

Master. thlS case the router is 

Exchange 

Database slave to retransmit the last 

^tpliS: Chat " ^ S£nt " (the packet 

° ^scer/s^ve stated "ith . the 

— event K^SS^ ^ 



o 
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set 



DD 



o If the packet* s Options field indicates a different 

of optional OSPF capabilities than were previously 
received from the neighbor (recorded, in the Neighbor 
Options field of the neighbor structure) , generate the 

neighbor event SeqNumberMismatch and stop processing the 
packet. 

o Database Description packets roust be processed in 
sequence, as indicated by the packets* DD sequence 
numbers. If the router is master, the next packet 
received should have DD sequence number equal to the 

sequence number in the neighbor data structure. If the 
router is slave, the next packet received should have DD 
sequence number equal to one more than the DD sequence 
number stored in the neighbor data structure. In either 
case, if the. packet is the next in sequence it should be 

accepted and its contents processed, as specified below. 

o Else, generate the neighbor event SeqNumberMismatch and 
stop processing the packet. 

Loading or Full 

In this state, the router has sent and received an entire 
sequence of Database Description Packets. The 
only packets 

received should be duplicates (see above) . In particular, 
the packet's Options field should match the set of 

OSPF capabilities previously indicated by the neighbor 
(stored in the neighbor structure's Neighbor Options field). 
Any other packets received, including the reception of a 

packet with the Initialized) bit set, should generate the 
neighbor event SeqNumberMismatch. [8] Duplicates should be 
discarded by the master. The slave must respond to 
duplicates by repeating the last Database Description 

that it had sent. 



optional 



packet 



When the router accepts a received Database 

Description Packet 

as the next in sequence the packet contents are processed as 
follows. For each LSA listed, the LSA's LS type is checked for 
validity. If the LS type is unknown (e.g., not one of the LS 
types 1-5 defined by this specification), or if. this is an AS- 

external-LSA (LS type = 5) and the neighbor is associated with a 
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stub area, generate the neighbor event SeqNumberMismatch and 
stop processing the packet. Otherwise, the router looks up the 
LSA m its database to see whether it also has an instance of 
the LSA. If it does not, or if the s database copy is less 

recent 

(see Section 13.1), the LSA is put on the Link state request 
list so that it can be requested- (immediately or at some 

.Later 

time) in Link State Request Packets. 

When the router accepts a received Database 

Description Packet 

as the, next in sequence, it also performs the 
following actions, 

depending on whether it is master or slave: 

Master 

Increments the DD sequence number in the neighbor data 
structure. If the router has already sent its entire 
sequence of Database Description Packets, and the just 
accepted packet has the more bit (M) set to 0, the neighbor 
event ExchangeDone is generated. Otherwise, it should send 
a new Database Description to the slave. 

Slave 

Sets the DD sequence number in the neighbor data 

structure 

to the DD sequence number appearing in the 
received packet. 

The slave must send a Database Description Packet in 

If the received packet has the more bit (M) set to 0, 

the packet to be sent by the slave will also have the M- 

set to 0, the neighbor event ExchangeDone is generated 

Note that the slave always generates this event before the 
master. 

10.7. Receiving Link State Request Packets 

This section explains the detailed processing of received Link 
State Request packets. Received Link State Request Packets 
specify a list of LSAs that the neighbor wishes to receive 

Link State Request Packets should be accepted when the neighbor 
is in states Exchange, Loading, or Full. In all other states 

Link State Request Packets should be ignored. 



reply. 

and 

bit 
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summary list when the previous packet is acknowledged. 

In state Exchange, the determination of when to send a 

Database 

Description packet depends on whether the router is master or 
slave: 



Master 

Database Description packets are sent when either a) the 
slave acknowledges the previous Database Description packet 
by echoing the DD sequence number or b) Hxmt Interval seconds 
elapse without an acknowledgment, in which case, 
the previous 

Database Description packet is retransmitted. 

Slave 

Database Description packets are sent only in response to 
Database Description packets received from the master. If. 
the Database Description packet received from the master 

is 

new, a new Database Description packet is sent, otherwise 
the previous Database Description packet is resent. 

In states Loading and Full the slave must resend its last 
Database Description, packet in response to duplicate Database 
Description packets received from the master. For this reason 
the slave must wait Route rDeadlnterval seconds before freeing 
the last Database Description packet. Reception of a Database 
Description packet from the master after this interval will 
generate a SeqNumberMismatch neighbor event. 

10.9. Sending Link State Request Packets 

In neighbor states Exchange or Loading, the Link, state request 
list contains a list of those LSAs that need to be 

obtained from 

the neighbor. To request these LSAs, a router sends the 

neighbor the beginning of the Link state request list, packaged 
in a Link State Request packet. 
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When the neighbor responds to these requests with the- proper 
Link State Update packet(s), the Link state request list is 
truncated and a new Link State Request packet is sent. This 
process continues until the Link state request list becomes 

empty. LSAs on the Link state request list that have been" 
requested, but not yet received, are packaged into Link State 
Request packets for retransmission at intervals of 

Rxmtlnterval . 

There should be at most . one Link State Request packet 
outstanding at any one time. 



the Shbor tink State reqUeSt list bec °- s -Pty. and 

state is Loading (i.e.. a complete sequence of Da ta >»„ 
Description packets has been sent ^0^*0^ fro» t h„ 
neighbor, . the Loading Done neighbor event is a^erac^ 



?: P . P ackets h ^s been sent to and received f™»\ 
neighbor), the Loading Done neighbor event is general! 

10.10. An Example 

x ssrs K e ?i^r" * ~* ~— — «««« - 

Packet indicates that it is itself fch~ nl' .«* » its next Hello 
that it has neard Helio Packets f^™*"^ 

turn causes CJCecs from RT1_ This in 

RT1 to go Co state ExStart a<? in . . 

adjacency. ' aS Xt start * to bring up the 

*Zl be ^ ins b V asserting itself as the master Wh*>« ; r 

RT2 is indeed the master (because of r?5*« k : k ^ fc Sees that 

RT1 transitions to slave state ant adLf ? ^ ^ ter ID) ' 

se^ence number . Databas^ S^S^S^^^^ ™ 

exchanged, with polls coming from the master „ 

from the slave (RT1) : This ^guence o| Databisf Ls^ipc!^" 
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|RT1| 

|rt2|. 



Down „ 

Down 

Hello(DR=0,seen=0) . 
Hello (DR=RT2,seen=RTl, . . .) "^nit 
ExStart D-D ( Seq= x ; I , Master)" 



D-D (Seq=y,r.M /Master) ExStart 
Exchange ^ D-D (Seq=y, M, Slaved 

< ^eq=y+l,M. Master) ^Exchange 

D-D <Seq=y+l,M. Slave) 

■ > 

D-D (Seq=y+n, Master) 

<— 

- - Pr P. ( Seq=y±n^_aiave)- - 

Loading — 

LS Request Full, 

I>S Update 

< • ■ 

LS Request 

LS Update 

<. 

Full * 
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Figure 14 : An adjacency bring-up example 



the 



Packets ends when both the poll and associated response has 



M-bit off. 

example, it is assumed that RT2 has a completely 

case, RT2 goes immediately. 



up to 

date database. in that 
into Full 

necessary^" ^ 9 ° int ° F " U State after "P^ting the 

state . parts of its database. This is done by sending Link 

Notf et that? d „h r rie ei K T " 9 *}£ * 
set ' niXe RT1 has waited until a complete 

of Database Description Packet-* u 

before sending an^Link State Request Packet <f ro » ™> 

the case rti r-™,i^ w • request Packets, thxs need not be 

Request Packets ^ Sendih9 ° f Lin * St ^e 

Packets. Packets With the reception of Database Description 



11. The Routing Table Structure 



The routing table data structure contains all the 

information- 

necessary to forward an IP data packet toward, its destination. Each 
routing table entry describes the collection of best paths to a 
particular destination. When forwarding an IP 

data .packet, the 

routing table entry providing the best match for the packet's IP 
destination is located. The matching routing table entry then 
provides the next hop towards the packet's destination. OSPF also 
provides for the existence of a default route (Destination ID =■■ 
DefaultDestination, Address Mask = 0x00000000) when the 

default 

route exists, it matches all IP destinations (although any other 
matching entry is a better match) . Finding the routing table 

entry 

that best matches an IP destination is further described 
in Section 
11.1. 

There is a single routing table in each router. Two 
sample routing 

tables are described in Sections 11.2 and 11.3. The building of the 
routing table is discussed in Section 16. 
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The rest of this section defines the fields found, in a 

routing table 

entry. The first set of fields describes the routing 
table entry's 

destination . 

Destination Type 

Destination type is either "network- or "router". Only network 
entries are actually used when forwarding IP data traffic. 

Router routing table entries are used solely as intermediate 
steps- in the routing table build process. 

A network is a range of IP addresses, to which IP data traffic 
may be forwarded. This includes IP networks (class A, B or C) 
IP subnets, IP supersets and single IP hosts. The default route 
also falls into this category. 

Router entries are kept for area border routers and AS 

boundary 

routers. Routing table entries for area 

border routers are used 

when calculating the inter-area routes (see Section 16.2), and 

when maintaining configured virtual links (see Section 15) . 
Routing table entries for AS boundary routers are used when 

calculating the AS external routes (see Section 1.6.4). 



Destination id 

The destination's identifier or- n^m^ • 3 " , 

Destination Type. For nlt^rZ, the^ti^ t?^™ 

5S?»fiJf address - For routers - the "-Stti^u'lL 0SPF 

Address Mask 

SS xtfaddre^ ^sTSiner: "^K* ™ ****** 

,or nost routes ' the "ask xs •all ones' <Oxf ffffff f ) 
Optional Capabilities 

When the destination is a router this field indicates the 
destina^on n ro U °er P :«««*- the 

drscussxon of OSPF's optional capabilities, see iection 4.5. 
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on 



^the OSPF' ° f PatHS tC USS f ° r a destination »ay vary based 

^cipL W routin^able S en^ie S 9 for^"^ T " ^ — *- 

on the values ol the next field destination, depending 



Area 



type "network", onlv the «?^h 

area (the one p™^^^^^t~^ the best 

pathfto ° f r ° Uting table ent ^ describes the set of 

paths'" deStinati °"- ™e following fields pertain to the set of 



Path- type 



There are four possible types of paths used to route traffic to 
the destination, listed here in decreasing order of 
preference: 

intra- area, inter-area, type 1 external or type 2 external 

Intra-area paths indicate destinations belonging to one of the 

router's attached areas. Inter-area paths are paths to 
destinations in other OSPF areas. These are 
discovered through 

, ^r^ i 2 at ^° n -° f received summary- LSAs. AS external paths are 
paths to destinations external to the AS. These are detected 
through the examination of received AS-external^LSAs. 

Cost 

The link state cost of the path to the destination. For all 

. paths, except type 2 external paths this describes the entire 
path s cost. For Type 2 external paths, this field describes 
the cost of the portion of the path internal to the AS. 
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cost is calculated as the sum of the costs of the path's 

constituent links. p ■ 

Type 2 cost 

° nl ^ val i d for tv P* 2 external paths. For these paths, this 
This lndlC8tes the CbSt of the ^ th ^ external portion, 

cost has been advertised by an AS boundary router, and is the 
most significant part of the total path cost. For example a 
type 2 external path with type 2 cost of 5 is always preferred 

th!M P 2 C ° St ° f 10 ' ^ardless of the cost^f 

the two paths ' internal components. 

Link State Origin 

Valid only for intra-area paths, this field indicates the LSA 
(router-LSA or network-LSA) that directly references the 
destination. For example, if the destination is a transit 
network, this is the transit network's network-LSA. If the 
!! ti w a ^° n iS a Stub ne , twor *' this is the router-LSA for the 

tree^atcuT^" ^ iS discover * d ^ing the shortest-path 

tree calculation (see Section 16.1). Multiple LSAs may 

HdZlT* th ^ h de \ tination ' however a tie-breaking scheme always 
field ^ t0 a single LSA. The Link State Origin 

is not used by the OSPF protocol, but it is used by 
the routing y 

(M0SPFr 1CUlaCi ° n in 0SPF ' S ' Multicast extensions. 

When multiple paths of equal path- type and cost exist to a 
are stored 10 " ' Called elsewhere "equal-cost" paths) . they 

paths" ' Si " 9le rOUtinS t3ble eriCry - Each one ° f che 'equal-cost- 



is distinguished by the following fields: 



Next hop m 

The outgoing router interface to use when forwarding traffic to 
the destination. On broadcast, Point- to-MultiPoint and NBMA 

networks, the next hop also includes the IP address of the next 
router (if any) in the path towards the. destination. 

Advertising router 

Valid only for inter-area and AS external paths. This field 
indicates the Router ID of the router advertising, the summary- 
LSA or AS-external-LSA that led to this path. 
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11.1. Routing table lookup 

When an XP data packet is received, an OSPF router finds 

the m 

routing table entry that best matches the packet's 

destination . 

This routing table entry then provides the. outgoing, interface 
and next hop router to use in forwarding the packet. This 
section describes the process of finding the best matching 

routing table entry. 

Before the lookup begins, "discard* routing table entries should 
be inserted into the routing table for each of the router's 
active area address ranges (see . Section. .3.5). (An 
area range is 

considered, "active" if the range- contains one or more networks 
reachable by intra-area paths.) The destination of a* 

"discard" 

entry is the set of addresses described by its associated active 
area address range, and the path type of each "discard* entry 

is 

set to " inter-area* . (101 

Several routing table entries may match the 

destination address . 

In this case, the "best match* is the routing table entry 

that ' 

provides the most specific (longest) match. Another way of 
saying this is to choose the entry that specifies the narrowest 
range of IP addresses .( 11 ] For example, the. entry for the 
address/mask pair of (128.185.1.0, OxffffffOO) is more specific 
than an entry for the pair (128.185.0.0, Oxf fffOOOO) . The 

default route, is the least specific match, since it matches 

all • - 

destinations. (Note that for any single routing table entry, 

multiple paths may be possible. In these cases, the 

calculations 

in Sections 16. 1, 16.2, and 16.4 always yield the paths having 
the most preferential path-type, as described in Section 11). 



rf. there is no matching routing table entry, or the best 

match 

routing table entry is one of the above -discard" routina 

table 9 

entries, then the packet's IP destination is considered 
unreachable. Instead of being forwarded, the packet should then 
be discarded and an ICMP destination unreachable message should, 
be returned to the packet ' s source . 

11-2. Sample routing table, without areas 

Consider the Autonomous System pictured in Figure 2. No OSPF 
areas have been configured. A single metric is shown peir 
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outbound interface. The calculation of Router RT6's routing 
table proceeds as described in Section 2.2. The resulting 
routing table is shown in Table 12. Destination types axe 

abbreviated: Network as *N", Router as "R-: 

There are no instances of multiple equal-cost shortest paths in 
this example. Also, since there are no areas, there are no 
inter-area ^paths . 

Routers RT5 and RT7 are AS boundary routers. Intra- 

area routes 

have been calculated to Routers RT5 and RT7. This allows 

external routes to be calculated to the destinations advertised 
by RT5 and RT7 (i.e.. Networks N12, N13, N14 and NX5) It is 

assumed all AS- external -LSAs originated by RT5 and RT7 are 

advertising type 1 external metrics. This results in type 1 
external paths being calculated to destinations N12-N15 



11.3. Sample routing table, with areas 

.Consider the previous example, this time split into OSPF areas. 
An OSPF area configuration is pictured in Figure 6 Router 

RT4's routing table will be described for this area 
configuration. Router RT4 has a connection to Area 1 and a 
backbone connection. This causes Router RT4 to view the AS as 
the concatenation of the two graphs shown in Figures 7 and 8 
The resulting routing table is displayed in Table 13. 

Again, Routers RT5 and RT7 are AS boundary routers Routers 
RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that 
there are two routing entries for the area border router RT3 , 
since it has two areas in common with RT4 (Area 1 and the 
backbone) . 

Backbone paths have been calculated to all area border routers 
These are used when determining. the inter-area routes. Note 

that all of the inter-area routes are associated with the . 
backbone; this is always the case when the calculating router is 



has 



itself an area border routPr » 

_ , je . ^ le ' we assume that Area 3 
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Type Dest 



Area 



Path 



N 
N 
N 
N 
N 
N 
N 
N 
N. 
N 

N 

N 

N 

R 

R 

N~~ 
N 
N 
N 



Type Cost 
Hop(s) 



N2 

N3 

N4 

lb 

Xa 

N6 

N7 

N8 

N9 

N10 

Nil 

HI 

RT5 

RT7 

N12 
N13 
N14 
N15 



Next Adv. 
Router (s ) 



0 

0 

0 
0 



0 
0 
0 
0 
0 
0 

0 

0 

0 

0 



intra 
intra 
intra 
intra- 
intra- 
intra- 
intra- 
intra 
intra 
intra 
intra - 
intra- 
intra- 
intra- 
intra 



-area 
area 
-area 
-area 
-area 
-area 
area 
area 
-area 
-area 
-area 
-area 
-area 
-area 
area 



type 
type 
type 
type 



1 ext . 
1 ext. 
1 ext. 
1 ext. 



10 


RT3 


* 


10 


RT3 


* 


7 


RT3 




8 


RT3 


* 


7 




* 


12 


RT10 


■ * 


8 


RT10 




12 


RT10 


* ■ 


10 


RT10 


* 


11 


RT10 


* 


13 


RT10 


* 


14 


RT10 


* 


21 


RT10 


* 


6 


RT5 


*- 


8 


RT10 


* . 




10 


RTia 




14 


RT5 




14 


RT5 




17 


RT10 



RT7 
RT5 
RT5 
RT7 



«•• it - co 
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the 



Router RT4's routing table- would improve (i e somo nf 
paths in the routing table would Some shor^rl^f " 
additional virtual lin* were configured £^ > f Router RT4 

wrtrthffirst^ntrT lofare * associated 

intra-area path cnxo^h ~ ^ ^ ia Table 13 (an 

g Area 1J ■- Thi * would yield a cost of 



and 
1 

that 

are sho^ ^ W th * a ^tio„ of this 



intra-area path 

for the virtual linJc ; ^ rout . n? table entries 

virtual link 



Adv. 



Type 



Dest 



N 
N 
N 
N 
R 



N 
N 
R 
R 
R 
R 
R 



Nl 
N2 
M3 
N4 
RT3 



lb 

la 

RT3 

RT5 

RT7 

RT10 

RT11 



Area Path Type Cost 

Hops(s) Router (s) 



Next 



1 
1 
1 
1 
1 



intra-area 
intra -area 
intra-area 
intra-area 
intra-area 



0 
0 
0 
0 
0 



intra-area 
intra-area 
intra-area 
intra-area. 
intra-area 



intra-area 
intra-area 



4 


RT1 


*- 


4 


RT2 


*■• 


1 




'*■ 


3 


RT3 


* 


1 


* 


* 


22 


RT5 


* 


27 


RT5 


* 


21 


RT5 


* 


8 


* 


* 


14 


RT5 






22 


RT5 




25 


RT5 



N N6 0 

N . N7 o 

N N8 0 
N N9-N11,H1 0 



N 

N. 
N 
N 



inter -area 
inter-area 
inter-area, 
inter-area 



15 
19 
18 
36 



RT5 
RT5 
RT5 
RT5 



RT7 
RT7 
RT7 
RT11 



N12, 
N13 
N14 
N15 



type 1 ext. 
type 1 ext. 
type 1 ext. 
type 1 ext. 



16 
16 
16 
23 



RT5 
RT5 
RT5 
RT5 



RT5 , RT7 
RT5 
RT5 
RT7 



Table 13: Router RT4's routing table 

in the presence of areas. 
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in Table 14. 



12. Link State Advertisements ,LSAs) 

more^rinr"^ ** Che A ^°nomous System ori ginates one or 

forms the link-state oata^sV The «^ ofTsL 

external-LSAs provide a w ay of ' 

externally-derived routing inf «™f.- ^ ra " S ? arent1 *' advertising 
Systero - 9 nf0rmatl0n throughout the Autonomous 

Z2£X23Z. M 3 header. ^ ^ ^ ^ 



Adv. 



Type 



Dest 



N 
N 
R 
R 
R 



Area 



Path Type 



Cost 



Next 



lb 

la 
RT3 
RT10 
RT11 



0 
0 



Hop(s) Router (s) 



xntra-area 16 
intra-area 21 

0 intra-area 

0 



xntra-area 
intra-area 



RT3 
RT3 
1 

16 
19 



inter-area 



30 



RT3 
RT3 

RT3~ 



RT11 



Table 
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".1. The LSA Header 

Adve^Ling Router S££" ^T' 4«* ID -and 

fields unxquely identifies the ^"^^n of. these th ° ee 

There may be several inch 

k= ssn-i, :1F^-" - » -'-X 



byte lIa" 3 - 711636 Eields « e als ° contained in the 20- 

header. . 

State ID and Advertising Router r«L , LS CyPC ' Link 

Packets). Otherwise, . tL « " ' *ee Lxnk state Request 

checksum fields -rt als^^rLced^"' ~* M 

12.1.1. LS age 

This field is the age of the !.<;» i*. ^ 

processed as an unsigned l^bif^^. seconds It should be 
when the LSA is originated " t ^ t " is set *° 0 

InfTransDelay on every hop of rt. ri^ increre *»ted by 

also aged JZ^Jt^Ji^S P^edure. LSAs 



LSAs 

is 
is 

LSAs, 



also aged * Ware SS^S SSS^St. 

MaxAge. 

. — le 

age first reaches MaxAge, it 
reflooded. An LSA of . age MaxAge 
rxnaxiy flushed . from 



The age of an LSA is never incremented past 

having age MaxAge are not ns«i i„ 

calculation. When an L^A's ln _ the . rout "9 table 



from the 



consult Section 14. 

The LS aae fi*»1r 

receives two 18 examined when a router 



nS e ^ f a L^hecL 0 u ms haV r identiCal LS -*~ 

^ checksums. An instance of age MaxAge is then 

Standards Track [Page ■ 
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. ' nSd^SS ^r 3 ^^^^" OW LSAs to he 

ages differ by "ore h ' Otherwise, if the 

the y more than MaxAgeDxff, the instance having 

scalier age is accepted as most recent. (12) See-Section 
for more details. 

12.1.2. Options 
which optional ° ptlons f ield in the LSA header indicates 



bits 
This 

backbone , 
it 



the 



capability is defined by this specification, represented by 
the E-bxt found in the Options field. The unrecognized 

in the Options field should be set to zero. 

The E-bit represents OSPF's Externa iRoutingCapability . 

bit should be set in all LSAs associated with the 

3 n 6> l^'ihlftS a f SOC i ated with non-stub areas (see Section 

«L ■» j I should also be set m all AS- external -LSAs . it 
should be reset in all router-LSAs, network-LSAs and 
suncnary-LSAs associated with a stub area. For all LSAs, the 
setting of the E-bit is for informational purposes oniy; 

does not affect the routing table calculation. 

12 . 1 . 3 . LS type 

The LS type field dictates the format and function of 

LSA. LSAs of different types have different names (e a 
router-LSAs or network-LSAs) . All LSA types defined this 
memo, except- the AS- external -LSAs (LS type = 5) , are flooded 
throughout a single area only. AS— external— LSAs are flooded 
throughout the entire Autonomous System, excepting stub 
areas (see Section 3.6). Each separate LSA type 
briefly J ^ 
described below in Table 15. 

12.1.4. Link State ID 

This field identifies the piece of the routing domain that 

tvoe^tL r eSC ^^ d * ******* °n^he U^l! 

type, the Link State ID takes on the values listed in Table 
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LS Type LSA description 



These are the. router-LSAs . 
They describe the collected 

states of the router's 
interfaces. For more information, 
consult Section 12.4.1. 



These are the network-LSAs. 
They describe the set of routers 
attached to the network. For 
more information, consult 
Section 12.4.2. 

or 4 These are the summary-LSAs . 



They describe inter-area routes, 
and enable the condensation of 
routing information at area 
borders Originated by area border 
routers, the Type 3 summary-LSAs 
describe routes to networks while 
Type. 4 summary- LSAs describe routes 
AS boundary routers. 



the 
to 



These are the AS-external-LSAs 
Originated by AS boundary routers, 
they describe routes 
to destinations external to the 
Autonomous System. A default route for 
the Autonomous System can also be 

described by an AS-external-LSA. 



Table 15: OSPF link state advertisements (LSAs) . 
16. 



Actually, for Type 3 summary-LSAs ( L S tvoe - 31 
extemal-LSAs (LS type = 5K the Lint sSL'mJS*' 



AS- 
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LS Type Link State ID 

1 The originating router's Router ID 

2 The IP interface address of the 
network's Designated Router 

3 The destination network's. IP address 

4 The Router ID of the described AS 
boundary router. 

5 The destination network's IP address. 



Table 16; The LSA's Link. State ID. 
"host-°biJs y ""set T ° r ° f thG dest i™tipn network's 

When the LSA is describing a network (LS type = 2, 3 or 5) 
the network's IP address is easily derived by rnaskLg' the 



Link State ID with the network/subnet, mask contained in th* 

52 - it *f th- ^ J*" " - *^W^StS. ?£ 

described ** ' Che Ll?lk State lb always the 

router ■ s OSPF Router ID. 

When an AS-external-LSA (I*s Tvne = 5> i« rfoeMw- 

default route, its Link State iD^ S e^ to lbln3 a 

DefaultDestlnatibn (0.0.0.0). 



the 



This field specifies the OS FP Router ID of the LSA's 
orxgxnator. For router-fcSAs, this field is identical to 



12.1 . 5 . Advertising Router 

This field specifies the OS 
originator- For routers 

Link State ID field. Network-I^As are originated by the 
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DeSiSnat ^ R ° Ut?r - Sun.mary-tSAs originated by 
. bo^ d r e o r uter:: terS - are originated^ AS 

12.1. 6 . LS sequence number 

It is nu^er field is a signed 32-bit integer, 

used to detect old and duplicate LSAs. The space of 

the constant 2**31. 

The sequence number -N (0x80000000) i s reservM ,^ nr > 

=u«„s;i las, -^«rr th - :sr2 " 

is ref ^rr^ri V«' « 4 e nun tt>er; this sequence number 

<0x7ff£ffff? also n ^~ r ^* st th e maximum value of N - 1 
has been acknowledged by al^adiacent 11°^ fl °° d 

number of ^ r ° Uter b& £ ° rced to. promote. the sequence 



one 



of its LSAs when a more recent' instance of the LSA 



unexpectedly received during the flooding process . This 
should be a rare event. This may indicate that an out-of- 
date LSA, originated by the router itself before its last 
restart/reload, still exists in. the Autonomous System. For 
more information see Section 13:4. 
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12.1.7. LS checksum 

This field is the checksum of the complete contents of the 

LSA, excepting the LS age field. The LS age field is 
excepted so that an LSA's age can be incremented without 

updating the checksum. The checksum used is the same that 

is used for ISO connectionless datagrams; it is commonly 
referred to as the Fletcher checksum. It is documented in 
Annex. B of [Ref 6) . The LSA header also contains the 



length 



LSA. 



it 



See 



of the LSA in bytes; subtracting the size of the LS age 
field (two bytes) yields the amount of data to checksum. 

The checksum is used to detect data corruption of an 

This corruption can occur while an LSA is being flooded, or 
while it is being held in a router's memory. The LS 
checksum field cannot take on the value of zero; the 
occurrence of such a value should be considered a checksum 
failure. In other words, calculation of the checksum is not 
optional. 

The checksum of an LSA is verified in two cases: a) when 

is received in a Link State Update Packet and b) at times 
during the aging of the link state database. The detection 
of a checksum failure leads to separate actions in each 

case. See Sections 13 and 14 for more details. 

Whenever the LS sequence number field indicates that two 
instances of an LSA. are the same, the LS checksum field is 

examined. If there is a difference, the instance with the 
larger LS checksum is considered to be most recent. [13] 

Section 13.1 for more details. 

12.2. The link state database 

A. router has a separate link state database for every area to 
which it belongs. All routers belonging to the same area have 
identical link state databases for the area! 



The databases for each individual area are always dealt with 
separately. The shortest path calculation is performed 
separately for each area (see Section 16) . Components of the 
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only area link-state database are flooded throughout the area 

Finally, when an adjacency {belonging to Area A) is being 
brought up, only the database for: Area A is synchronized 

Between 

the two routers. 

The area database is composed of router-LSAs, network-LSAs and 
summary-LSAs (all listed in the area data structure) In 

addition, external routes (AS-external-LSAs) are included in all 
non-stub area databases (see Section 3.6). 

An implementation of OSPF must be able to access individual 
pieces of an area database. This lookup function is based On an 
LSA^LS type, Link State: ID and Advertising Router: [14 J There 
each LSA i^T * Single instMce: I the most up-to-date) of 

the database The database lookup function is invoked during 
the LSA flooding procedure (Section 13) and 

the routing table 

calculation (Section 16) . In addition, using this lookup 
function the router can determine whether it has itself ever 
nu^er^ 6 * 1 a particular hSA ' m * if so, with what LS sequence 

An LSA is added to a router's database when either a) it is 
received during the flooding process (Section 13) or b) it is 
originated by the router itself (Section 12 4) An 

LSA is «** 

deleted fro™ a router's database when either a) it has been 

S 3 newer w instance during the flooding process 

l f 1l ° ° r • b> ^ r ° Uter ori 9 in ates * "ewer instance of one 

of its self-originated LSAs (Section 12.4) or c) the LSA ages 
out and is flushed from the routing domain (Section 14) 

Whenever an LSA is deleted from the database it must also be 
removed from all neighbors' Link state retransmission lists 

Section 10) . 



(see 



12 . 3 . Representation of TOS 

For backward compatibility with previous versions of the OSPF 

specification ((Ref9J), TOS-specific information can . 
be included 

in router-LSAs, summary-LSAs and AS-external-LSAs 
The encoding 

of TOS in OSPF LSAs is specified in Table 17. That table relates 

,o S !f,?? C ° dinS t0 the IP Packet header's TOS field (defined 
in(Refl21). The OSPF encoding is expressed as I decimal 
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integer, and the IP packet header's TOS field is expressed in 
the binary TOS values used in f'Ref 12.J . 



OSPF encoding RFC 1349 TOS values 

0 0000 normal . service 

2 0001 minimize monetary cost 

4 0010 maximize reliability 

5 0011 

8 0100 maximize throughput 

10 0101 

12 0110 

14 oill 

I 6 1000 minimize delay 

18 1001 

20 1010 

22 1011 

24 1100 

26 hoi 

28 mo 

30 mi 

Table 17; Representing TOS in OSPF. 

12.4. Originating LSAs 

Into any given OSPF area, a router will originate several LSAs. 
Each router originates a router.-LSA. If the router is also the 
Designated Router for any of the area's networks, it will 
originate network-LSAs for those networks . 

Area border routers originate a single summary-LSA for each 

known inter-area, destination. AS boundary routers originate a 
D~H 6 ^ S - externai - LSA for each known AS external destination. 

Destinations are advertised one at a time so that the change 



entire 



any single route can be flooded without reflooding the 

collection of routes. During the flooding procedure, many LSAs 
can be carried by a single Link State Update packet. 
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As an example, consider Router RT4 in Figure 6. It 



is an area 



Router RT4 will ^ i , . . 



>~t- «« .ill b. «i„i«. tIl „ 3 

3-6). instead. Bout ^ lnt ° area 3 (see Section 

send their AS external traffic to RTl"* 3 ' S internal routers to 

LS Te^Z:i " inSta " ce «* is origins*,, its 

number is incremented. i ts lc' „ . 

xs calculated, and the Lsa if SLjlV" S° °' " S M checksum 
and flooded out the appropriacf i ^ State <3ataba^ 

for details concerning ?£e L^llation^I^e & SE^"* 
state database c P p • 

flooding of newly originat ed°LSAs ' details kerning the 

^ ^ The ten events that _ cause & _ ^ 

originated are: 

(1) The LS age fielH 

" ° f ° n . e ° f the iter's self-originated 

^tancVof the^s^"^ 1 "*- In thi * a new 

contents the " originated, even tAough the 

periodic updating of K»« nations of all LSAs . This 
algorithm/ LSAs that loleg E^"- C ° Unk 
destinations should not be rerrf^T t "tenable 
exushed from the ^ttlSl^iS^f,}--*-- - 
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When whatever is being descriho^ k 

originated. However Awo install ^ ^ Chang6S ' a n 
originated within the time Zl^x 5-°5 * he Same LSA 



orxg.nated within the Cime P^S^&S^."^^ «t be 



that the generation 6 f the next instance be 



require 
delayed by 

originations j£ on^Tf tSS^^'T^ ShOUld «~ 
would be . y lf the contents of the new 

different: 



LSA 



( see 



area 



area 



U> An interface's state changes (see Sectimr * ri ^ 

Router, any network-^ >2!j -J ™^°ns er ^ Designated 



Section 14.1) . 

f4) SL. SLs th ^ e ^tS? xTfr chanses to/£ra » 

instax.ee of tne^te^sf " ^"r^th 0 Pr0dUCe * 

the Designated Router fox rh/ff?' t J * router is itself 

networJc-LSA should be pro^ce^ attach «* "«~»*. a new 

The next four events concern area border routers only: 

« . f or this routed £"£ ^^^.£3^ 

(possibly including the backbone) . 

(but NEVER for the backbone) . 
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(7) The router becomes newly att-arh^ 

must then originate summary^LsL into tL ' Th& r ° Uter 

area for all pertinent iJ^ ? S newiy att ^ched 

the router's' i^i n TSl^^c^" ll ~-" rOII,: " in 

details. 9 table - See Section 12.4.3 for more 

(8) When the state of nnp t-u 

links changes, it ™ D f *°? f f^ virt«U 

router-LSA into the virtual ^ t° °^ 31nate a "ew 

virtual link's Transit area (see the 



discussion of the router-LSA's bit V in Section 12.4.1), as 
well as originating a new router-LSA into the backbone. 



AS 



The last two events concern AS boundary routers 
boundary routers) only: 



(and former 



(9) An external route gained through direct experience with an 
external routing protocol (like BGP) changes. This will 
cause an AS boundary router to originate a new instance of 
an AS- external -LSA. 



all 



(10) 



A router ceases to be an AS boundary router, perhaps- after 

restarting. In this situation the router should flush 



AS-external-LSAs that it had previously originated. 
LSAs can be flushed via the premature 

aging procedure 

specified in Section. 14 . 1. 



These 



the 



The construction of each type of LSA is explained in detail 
below. In general, these sections describe the contents of 

LSA body (i.e., the part coming after the 20 -byte LSA header). 
For information concerning the building of the LSA header, see 
Section 12.1. 



12.4.1. 



Router-LSAs 



A router originates a router-LSA for each area that it 
belongs to. Such an LSA describes the collected states of 
the router's links to the area. The LSA is flooded 

throughout the particular area, and no further. 
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192.1.2 



Area 1 



| 3+ + 1 

Nl | — | RT1 1 

+ --- + \ 

\ 

\/ \ 
* 192.1.1 *- 
+ /\ / 

! ■ ■ ' i 

I 3 + — -+1 / | 
N2 | |RT2 | + 



_N3 



1 + — - + 
|RT4 | 
+ + 



6+— + 



I 



RT3, 

192.1.3 , 2 - * + 

18.10.0.6(7 



192.1.4 (N4) " . 



Figure 15; Area 1 with IP addresses shown 
(Section f0rmat ° f * -uter-r^ is shown fa _ 

A. 4 .2) . The first 20 bytes nf 

generic LSA header that was S* * ^ cons "t of the 
router-LSAs have LS ^ = ^ s ™ssed in Section 12. f . 

A router also indicates M K«,i-». • . 

or an As boundary router fav ^^ " area border router 
external-LSAs . Bit B shn„7/i k_ 

actively attached to twS or SCt «"«™var the router is 

snould' nf^"* -"ac^ed 'to the^p^^— " theater 
should never be set in a router-LSA 5 ackbone *"a. Bit E 
areas cannot contain AS bounda^ ut J°f . * Stub ™ (stub 
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njore fully adjacent virtual endpoint of one or 

Transit area. The setting of bit ^ ^ Area A as the?r 

t t0 discov ^ whethfr the area ° ther ™«ers in 

(see TransxtCapability in Section 6) . SUpports traffic 

connections ter a^ ^terf the working 
link is typed according to thf W inks) to th * kach 
Each link is also labefl^ of attached network 

gives a name to the entity that i« IS 1 * ID " This Link ID 
link. Table 18 summarizes the 0 " ° ther ^ of the 
Link ID fields. * the values "sed for the Type and 




Interface address of 
Designated Router 
IP network number 



4 



Virtual link 



Neighbor Router ID 



link. 



Table 18: Link descriptions in the 
router-LSA. 

links linkS t0 Cransit networks, numbered point-to-point 

interface "* "f*? Xi ** 8 - this f i eld Reifies the » 

address of the: associated router , interface (this is heeded 
^^""txng table calculation, see Section xlA i) . 
links to stub networks, this field specifies the stub 

- OY Standards Track [Page 128} 

RFC OSPP Version 2 April 1 998 

ss^s i^. to stub — £ °-put co^ e 

To further describe the process of building the list of li^k 
descrrptrons. suppdse a router wishes to buildVrouter-^ 
interface . The r ° Uter "™»ines its collection of 

fre 3 Str tak^f S - *»^~-. «~ following steps 

Area A. no " ^ ""^ netW ° rk does n <* *»W to 

s^lVS ex d ^ned t0 ^ — -* interface 

° added" StaCe ° f interfa « " ^wn. no links are 

° Unk h T s tu aCe f vf he interface is Loopback, add a Type 3 
link (stub network) as long as this is not an interface 

and the cost set to o ,lndlCatln 9 a route). 

sLlion r POi -- 4 t0 i P ° in t inter ^ S - specifier 3 



Point- to-MultiPoinc interfaces in 12.4.1.4. 

a" 61 C ^ e rto ti t h VL a t 1 e r - t ^ r r^ int ~ f — -t H„ ks 
attached hosts belong To ^TtT^ ° f 

a nose route 

id i& - represented as a Type 3 link ^ network) ^ ^ 

all ones' 116 h ° St " S » addre ~ • Data is the MsJ[ „ f 

iSctf""" J : C ° St thB h ° St s con^aured cost (see ■ 
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12 . 4 . 1 . 1 . Describing point-to-point interfaces 

o If the neighboring router is f..11„ ^i- 

Type 1 link (point-to^oi^f £ ad ? acent - add a 
"t to the Router ID^f the ^ S^- 10 Sh ° Uld te 

numbered point-to-ooint ! neighboring router. For 

should specify the^P ^ r^' ^ Link ^ta 
unnumbered PoLt-to ^ ■ da «»»- *>r 

field shouirspeci^ 1 ^^"^: the Link Data 
iflndex value. Thexos^sS ^ 5 """^ tRef8 > 
cost of the point-to-^ 1 l?!:r t t0 the °«tput 



o 



uc sec c 

pomt-to-point interface. 
In addition, as lono « 

Option 1 

addr^s 9 '^is^o^ 191 ^"^ ™^ ip' 

«•* the^hb^s^ a^e ID ^ 3 

to the .as, 0X£ f f f f f f f Und^T^ 

' ana cne COst" hn . , 

configured output cost. [15] interface's 

Option 2 

Point S n n ^ s h et ^IVSIT^ t0 the P° in ^o- 
to the subnet s X ?s ^ ^ 3 link 
subnet's mask, and the St ^ ,t ■ ° ata to the 

configured output cost [16] ^ lnCerfa ^'s 



12.4.1.2. Describing broadcast and 



NBMA interfaces 



For operational broadcast- anH vmi« • 

link, description is adSr^ e ^ t ^%Tfo^ le 

Standards Track. (Page 130, 

OSP, Version, 

network number of the attached network. tin£ Data 
cost ^ t° attached network's address mask? and 

egual to the interface's configured output cost 

(transit network,^ ^Ak ^ 2 T J ink 
interface address of the attach^ ne^ork-s 

address, and cost equate the^terface^" 
configured output cost. Otherwise t v 

the interface «=»-;..-» utne "»xse. add a lank as if 

mcertace state were Waiting (see above) . 

12:4.1.3. Describing virtual links 

adjacent. In this «S ~L *"? al nei ?»»bor: is fully 

ni^ ? •^^■^^.r^as* 

cost calculated for thf • ^ C ° St Set fc o the 

the routing ° r the virtual link during 

table calculation (see Section 15) . 
12.4- 1.4 . Describing Point-to-MultiPoint interfaces 

follows: P °" S are added to the router-LSA as 



one or 



"ink^slr 6 o'tht ro S uttr"f WOrk) T * — 
address .Link O.tfT.^^ .nasToxff f S? f f^ 
(indicating a host route)> an<J cos f ! . 
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For each fully adjacent neighbor associated with 

interface/ add an additional Type 1 link (point-to- 
point) with Link ID se t to the Router ID of the 
neighboring router. Link Data set to the IP 
mterface^address and cost equal to the interface's 
configured output cost. 



that 



12.4.1.5. Examples of router-LSAs 

Consider the router-LSAs generated by Router RT3 as 

(Are^f ha/bf 1 " 6 " li ^ containing Router - RT3 

( Area 1) has been, redrawn, with actual network 

addresses in Figure 15. Assume that the last byte of 
all o f RT3 s interface addresses is 3, giving itfthe 
interface addresses 192.1.1.3 and 1 92. r. 4 .3, and that 
a^^o er r ° Uters * ave similar addressing schemes . In 
addition, assume that all links are functional. and 



Router IDs are assigned, as the smallest 
address . 



IP interface 



the 



RT3 originates two router-LSAs, one for Area 1 and 

for the^ backbone. Assume that Router RT1 has been 
selected as the Designated router for network^9?T\ 0 
RT3 s router-LSA for Area l is then shown below It 
indicates that RT3 has two connections to Area 1 the 
tirst a Imk to the transit network 1*2.1.1.0 and 

second a link to the stub network 192.1.4.0. Note that 
the transit network is. identified by the IP interface of 
its Designated Router (i.e. . the Link ID = 192 1 I 4 
192 C 1 l S of ° e *^* ted R ° Uter ™ >s IP interface to 

an k T alS ° that RT3 indicated that it is 

an area border router. 



RT3 ' 



router-LSA for Area 1 



LS age = 0 
Options 
LS type 



,„ ^. ; always true on origination 

— (Er-£>it) 

Link" State- ID I 192 .1.1.3 '^^^^ 
Advertising Router = 192.1.1.3 ;RT3>s Router ID 

;not an AS boundary router 
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bit B = 1 

#links = 2 

Link ID = 192.1.1.4 
Link Data = 192 .1.1.3 
Type =2 



;area border router 

;IP address of Desig. Rtr. 
;RT3*s IP interface to net 
/connects to transit network 



# TOS metrics =-■ 0 
metric = 1 



Link ID = 192.1.4.0 ; I P Network number 

Lxnk Data = OxffffffOO Network mask 
^S = metrics = 0 connects to stub network^ 

metric = 2 

Ne*t RT3s router-LSA for the backbone is shown It 

" ^ RT3 haS a sin 9 le attachment to the 
backbone. Th ls attachment is via" an unnumbered 
point-to-point link to Router RT6 rti h» = 

indicated that it is an area boToer router ^ 
; RT3 * s router-LSA for the backbone 

W5L~ ° = (E-bit, ;alwa ^ true on origination 

.Mn^tate ID I i 92 .l.i. 3 '^^olT^^ 

Advertising Router =192.1.1.3 ,RT3- S router ID 

bit B = , ;not an AS boundary router 

(tlinks = i ;area bor ^ router 

Link ID = 18.10.0.6 ~; Neighbor's' Router ID 

Link: Data = 0 0 0 3 -mtt» tt ^ t , ■ t 

Type = 1 !™~fL^ f ^ ° f P ~ P link 



; connects to router 



# TOS metrics = 0 
metric = 8 

12 - 4 - 2 • Network- LSAs 

NB^hetworf i ^ A 9 ?" erat r i f ° r CVery transit broadcast or 

-° y Standards Track (Page n3} 
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The Designated Router for the network originates the I <;a 

fully ^ . ^ eS3 -9nated Router originates' the LSA only if it is 

adjacent to at least one other router on the network Th» 

Router ID. The Designated Router includes itself "in this 
interface ^ ^ 10 f ° r 3 "etwork-LSA is the IP 



network-LSA) yields the network" s IP address' 

indicated by ^ tnJr ^nk^tace !D eo^rtr^^ 5 
router's TP ,'v, h ^(, OLCILe X1J equal to one of the 

12.4.2.1. Examples of network-LSAs 

£!twork°S er the ^configuration in Figure 6. 
x Network-LSAs are orrgmated for Network^ m in Area 

3. ' . networks N6 and N8 in Area 2, and Network *» in ^ 

Assuming that Router RT4 has been selected as t>,~ 
Designated Router for Network M3 th^„ff ? 

; NetworJc-LSA for Network N3 
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Rtr.. 



The 



LS age - 0 r 

Options = (E-bit) ;alwa y s true on origination 

LS" type = 2 ' • j> • 

Link State ID = 1 92 -1 £ 4 

Advertising Router , 192 . 11 . 4 ; R^s^ter 2 ^ 
Network Mask = Oxffffffoo «oucer id 

Attached Router = 192.1 1 4 . Bmit „ Tri 

Atta^hei rr = 1921:1:1 < : «°"~ ° 

Attach!rt D R ° U er = 1921 -l-2 ; Router ID 
Attached Router = 192.1.1.3 ; Router ID 

12-4.3. Summary- LSAs 

network^^n^^^unda^router ^T^"* i& eith " « IP 
Summary-LSAs are flooded^thro^L.^ ° f 1P add "sses. 

destination to^JTSS i/JS!^- Th * 

still belongs to the Autonomous System. 
Summary-LSAs are originated by area border 



precise summary routes to advertise into 
determined by examining th«» erclst \ . an area are 

structure (see examining the routing table 

below° n No te SLr CO f d, ^ Ce - With thC ■ WU- described 
into ° te that onl * "tra-area routes are- advertised 

routes baCkbDne - While b °th intra-area and inter . area 

advertised into the other areas. 

I' SrSC^^-^* Area 
Remember that, each rou^table LcrTSs-ifct f ° UoWS - 
egual-cost best paths to a wfcifaS&KS&f 

^ ; ar e ^er^^°r^t^r k ~ — 

the routing table *>^s. if 

border r ^ *• "rea . 

the next, routing table entry. 
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o Else, if the area associated with cwtw - * 

£tS5£ itself • do not £33^ j^ss^x 

° oeio^^o^rf i^! f as ao oc no a r d with this set ° f 

for the route. [18] This is theT*"*? 3 """"""V-^ 
Distance Vector protocols sZ^VrT^lo^^ °' ' 

o Else, if the routing table cost ~~ \ 

value LSInfinity. a suZn, r « ^als or exceeds the 

this route. suiuoary-LSA cannot be generated for 

° router" "Vsu^^V^ I™'* iS « *■ °°-dary 
if the routing^^entry'des^ if 
to the AS boundary router^see Sc^% * P refer "d path 
If so, a Type 4 sum ™™ • P 3 ° f Sec tion 16.4). 

hounda^—- ■"SSK.'S.*, 
^ Area A has been cSS^^"?^ 

° £^^S^?£^ If this is an 

y rate a Type 3 S ummary-LSA for the 



AS 



destination, with Link Stat*, rn 

address {i f neces he Link ST* t0 ^ ^twork-s 

one or more of the network -Th^ tate ID Can Mohave 
B for details, and metric e^uaf "'to T' *^.>**?°*i* 
cost. V***. to the routing table 

general, this informati™ ™ attached areas. i„ 
appearing i„ sum^™?^ l^^ 6 " ^ore 
configured list of address ^ a " ^ has a 

of an [address. mask) pa£ L a !** ran9e consisting 

either Advertise or Do^ot^ovtrtise "l?™ indi ~tion of^ 

— is generated SS/STK. £ ^ ^ 
Moy - 
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range ■ s address * • r 

also have one or more of neeess "y. the Link State TD can 
see Appendix E for detafls^ ^ ' " MtS " 

the largest cost of ™* cost equal to the 

y ° f the component networks. When 



su^mary-LSA ll't^J^S^"**^**. *Vpe 3 

regain hidden fro^othef a^f s ^ »t network 

elicit £' conf i^re^ 0 address°ran ot . COn ^ ained any 

is generated with Link ftJ ™' 3 T * pe 3 s — ary- 
network s address (if nec^f & ™ equal to the 
also have one or morf of the ^ Lin * State ™ can 

see Appendix E for details! and * * ""^ bits 
network's routing table cost ™ etriC equal to the 

If an area is caDah7» * 

its TransitCapabLity L ^o" 3 '""^ 
information concerning bac^ne ra "E) , routing 

condensed before beinn " acKDOn e networks should w 

should the adv^^Sn rrba^on"" 0 "» a ~ a «°r **. ** 
transit areas be suonrL^ " 6 ^ tworks in to 

backbone's conf igured r^s ^ ° ther w ° rds . the 

originating su^ary-Ls^to^r^it^rLT^ ^ 
If a router adverti^Pe 

then becomes unreachable thT^T^ f ° r 3 destination which 
from the routing domain by^t^"^ then flush the LSA 
reflooding (see Section 14 if ?? lt s age to MaxAge and 
still reachable, yet can no ? ls °' lf the destination is 
to the above procedure ? e g it'?" 3 ^ be advertised according 
when it used to be an i„t«-- r « n ° W an int ^-area route 

advert lsab r- baCkb ° ne ~ ' 

to the backbone) the LSA should also be flushed ^rom the 



routing domain. 



12.4.3.1. Originating summary-LSAs into stub areas 

The algorithm in Section 12.4.3 is optional when Area A 

is an OS PF stub area. Area border routers connecting to 
a stub area can originate summary-LSAs into the * . area 
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according to the Section 12 . 4 .3 's algorithm, or can 
choose to originate only a subset of the summary-LSAs, 
possibly under configuration control. The fewer LSAs 
originated, the smaller the stub, area's link state 

database, further reducing the demands on its routers' 
resources. However, omitting; LSAs may also lead to sub- 
optimal inter-area routing, although, routing will 
continue to function. 



LSAs 



As specified in Section 12.4.3,. Type 4 suamary- 

(ASBR- summary- LSAs) are never originated into stub 
areas. 

In a stub area, instead of importing external routes 

each area border router originates a. "default summary- 
LSA" into the area. The Link State ID for the default 
summary-LSA is set to DefaultDestination, and the metric 
set to the (per-area) configurable parameter 
StubDefaultCost. Note that StubDef aultCost need hot be 
configured identically in all of the stub area's area 
border routers . 

12.4.3.2. Examples of summary-LSAs 

Consider again the area conf igiiration in Figure 6. 

Routers RT3 , RT4, RT7 , RTIO and RT11 are all area border 

routers, and therefore are originating summary-LSAs. 

Consider in particular Router RT.4 . Its routing table 

was calculated as the example in Section 11.3. RT4 

originates summary-LSAs into both the backbone and. Area 

1.. Into the backbone, Router RT4 originates separate 

LSAs for each of the networks N1-N4. Into Area 1, 

Router RT4 originates separate LSAs for networks N6-N8 

and the AS boundary routers RT5 , RT7 . It also condenses 

host routes la and lb into a single summary- LSA. 

Finally, the routes to networks N9,N10,N11 and Host HI 

are advertised by a single summary-LSA . This 

condensation was originally performed by the router" 

RT11 . 
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These LSAs are illustrated graphically in Figures 7 and 
8 - Two of the summary- LSAs originated by Router RT4. 

follow. The actual IP addresses for the networks and 

routers in question have been, assigned in Figure 15. 

; Surranary-LSA. for Network Nl, 

; originated by Router RT4..into the backbone, 

LS age =0 ; always- true on origination 

Options = (E-bit) ; 

LS type = 3 ;Type 3 summary- LSA 

Link State ID =- .192. 1^2.0 ; Ml ' s IP network number 
Advertising Router =192.1.1.4 ;RT4's ID- 

metric - 4. 

; Surranary-LSA for AS boundary . router . RT7 ' 
; originated by Router RT4 into Area 1 

.LS age =0 ; always* true on origination 

Options = (E-bit) ; 

LS type. = 4 ;Type 4 summary- LSA 

Link State ID = Router RT7 • s ID 

Advertising Router = 192.1.1.4 ;RT4*s ID 

metric =14 

12 . 4 . 4 . AS-exterTial-LSAs 

AS- external -LSAs. describe routes to destinations external to 
the Autonomous System. Most AS- external -LSAs describe, 

routes to specific external. destinations; in these cases 

the - • \ 

LSA's Link State ID is set to the destination network's- IP 
address {if necessary, the Link State ID can also have one 
or more of the network's •host* bits set; see Appendix E for 
details) . However, a default route for the Autonomous 
System can be described in an ASrr external -LSA. by setting the : 
LSA's Link State ID to Def aultDestination (0 . 0 . 0 .0) . AS- 
external-LSAs are originated by AS boundary routers.. An. AS 
boundary router originates a single AS- external -LSA for 

each 

external route that it has learned,. either through another 
routing protocol (such as BGP) , or through configuration 
information. 
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AS-external-LSAs are the only type of LSAs that 
are flooded 

throughout the entire Autonomous System; all other types of 



link 



MaxAge 



LSAs are specific to a single area . However As-extern*! 

3 "ot ^Hif £1 ^r tti/ ^ b T StUb ^ ^Sectio'n 
' " niS enables a ; reduction, in link state database 

for routers, internal to stub areas 

one of two tapes' ' - Vernal route can be 

WO c yP es - Type 1 metrics are comparable to the 

the te ^cost " 2 m€ * rics turned to be larger than 

cne cost of any xntra-AS path. 

LSA from the routing domain by setting its age to 
and reflooding (see Section 14.1). 



12 . 4 . 4 . 1 . Examples of AS-external-tSAs 



l°T r t^. 0nce e a 9 ain th e AS pictured in Figure 6 There 
are two. AS boundary routers: RTS and RT7 Router rts 

Z rl ? 1Da Z^ AS-^ternal-LSAs. footworks N12 Nlf 

and " 'Nlf tW ° ^--temal^S^fo^ noLorxs 

-2 Sf anl^t^^co 1 ^ ^ ^ ^ 

AS-extemal-LSA for Network N12, 
originated by Router RT7 



; always true on origination 



LS age = 0 

Options .= (E-bit) 

r ? Ft? . = 5 ;AS~external-LSA 

Link State ID = N12 / s IP. network number 
Advertising Router =■ Router RT7*s ID 

bit B = i ;Type 2 metric 

metric = 2 y * raecric 

Forwarding address = 0.0.0.0 
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for 



RTC) 



In the above example, the forwarding address field 

has. been set to 0.0.0.0, indicating \hat Jackets 

a^rtisS^^^ f °— ded to the 

desirable ConaidW ^ *v 15 15 n0t alwa V s 

16 - c °nsider the example pictured- in Figure 

16 ; There are three OSPF routers ( RTA , RTB ^nd 



connected to a common network 
routers, RTA, is exchanging 



Only one of these 

BGP information with 



non-OSPE router RTX. RTA must then originate AS- 
external-LSAs for those- destinations it has learned 
from RTX. By using the AS-external-LSA's forwarding 
address field, RTA can specify that packets for 
these destinations be forwarded directly to RTX; 
Without, this feature. Routers RTB and RTC would take 
an extra hop to get to these destinations . 

Note that when the forwarding address field is non- 
zero, it should point, to a router belonging to 
another Autonomous. System. 

A f orwarding address can also be specified for the 
default route. For example, in figure 16. RTA may 
want to specify that all externally-destined packets 
should by default be forwarded to its BGP peer RTX. 
The resulting AS- external -LSA is pictured below. 

.Note that, the Link State ID is set to 

Def au It Destination . 

; Def ault route , originated by Router. RTA 
; Packets forwarded through RTX 

LS age = 0 ; always true on origination 

Options = (E-bit) 

LS type = 5 ; AS- external -LSA 

Link State ID = Def aultDestination ; default route 

Advertising Router = Router RTA's ID 

bit E = 1 ;Type 2 metric 

metric = 1 

Forwarding address = RTX's IP address- 
In f igure 16, suppose instead that both RTA and RTB 
exchange BGP information with RTX. In this case, 
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of AS- 



RTA and RTB would originate the same set 



external-LSAs. These LSAs, if 
they specify the same 

metric, would be functionally equivalent since they 
would specify the same destination and forwarding 
address (RTX) . This leads to a clear duplication of 
effort. If only one of RTA or RTB originated the 
set of AS -external -LSAs, the routing would, remain 

the same, and the size of the link state database 

would decrease. However, it must be unambiguously 
defined as to which router originates the LSAs 
(otherwise neither may, or the identity of the 
originator may oscillate) . The following rule is 

thereby established: if two routers, both reachable 

from one another, originate functionally equivalent 

AS-external-LSAs (i.e., same destination, cost and 
non-zero forwarding address), then the LSA 



originated by the router having the highest OSPF 
Router ID is used. The router having the lower OSPF 
Router ID can then flush its LSA. Flushing an hSK • 
is discussed in Section 14.1. 



+ + I . BGP 

Irta] 



... . . + +- 

|RTX| 



..... ,. 

r— i 

RTB | 



|RTC| — 

•-I 



Figure 16: Forwarding address example 
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13. The Flooding Procedure 

LSA S Link State ' t * date E,ackets Provide the mechanism f or : flooding 

flood^ ^ a h e U ?tt te P^ 1 "*™* contain several distinct LSAs, and 
Tq floods each LSA one hop further from its point of origination. 

acXno^dged fl0<>din9 - reliable* each LSA must be 

rr ra ^ Y ' Acknowledgments are transmitted in Link State 
Acknowledgment packets. Many separate acknowledgments can also be 
grouped together xnto a single packet. 

has floodin 9 Procedure starts when a Link State Update packet 

been received. Many consistency checks have been made on the 
(see reCeiVed PackeC before bei "3 handed to the flooding procedure. 

been SeCti ° n '"'^ ^ P " Cicular < che «4»* State Update packet has 

associated with a particular neighbor, and a particular area If 

packet" shou^ " ^ 3 l6SSer State than ^ . 

be dropped without further processing. 

with AU tyP6S ° f LSAS ' ° ther Chan AS -^emal-LSAs, are associated 



a specific area. However, LSAs do .not. contain an area field An 
LSA's area must be deduced from the Link State Update packet 
header. 

For each LSA contained in a Link State Update packet th~ 

following ' 
steps are taken: 

(1) Validate the LSA's LS checksum. if the checksum 

turns out to be 

invalid, discard the LSA and get the next one from the Link 
State Update packet. 

discard Examine the LSA ' S type. If the LS type is unknown, 

rw» _ ^ , get the next one fram the L ^ State 

Update Packet . 

This specification defines LS types 1-5 (see Section- 4 . 3) . 

(3) Else if this is an AS- external -LSA (LS type = 5) 

and the area * 

the beSn conf igured M a stub area » discard the LSA and get 

next one from the Link State Update Packet. AS-external-LSAs 
are not flooded into/ throughout * stub areas 

(see Section 3.6). 



is 



(4) Else if the ISA's LS age is equal to MaxAge, and there 

currently no instance of the LSA in the router's link state 
database, and none of router's neighbors are in states Exchange 
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^°^ ing ' ^ foll ^ing actions: a) Acknowledge the 

packet * Sending a Link State Acknowledgment 

back to the sending neighbor (see Section 13.5), and 

b) Discard 

*u r th \ LSA and examine the next LSA (if any) listed in 

trie Linx 

State Update packet 1 

(5) Otherwise, find the instance of this LSA that is 

currently 

contained in the router's link state database. If there is no 
database copy, or the received LSA is more recent than the 

whi^h^A 0 ^ tSee SeCti ? n below for the determination of 

which LSA is more recent) the following steps must be performed: 

(a) If there is already a database copy, and if the database 

copy was received via flooding and installed less than 
MinLSArrival seconds ago, discard the new LSA (without 
acknowledging it) and examine the next LSA (if any) listed 
in the Link State Update packet 



(b) Otherwise immediately flood the new LSA out some 
subset of 

the router ' s interfaces (see Section 13.3) . In some 

cases 

(e.g., the state of the receiving interface is DR and the : 
LSA was received from a router other than the Backup DR) 

the 

LSA will be flooded. back out the receiving 

interface. This 

occurrence should be noted for later use by the 
acknowledgment process (Section 13.5). 

(c) Remove the current database copy from all neighbors' Link 
state retransmission lists. 

(d) Install the new LSA in the link state database 
(replacing 

the current database copy) . This may cause. the 

routing 

table calculation to be scheduled. In addition, times tamp 
the new LSA with, the current time (i.e., the- time it 

was 

received). The flooding procedure cannot overwrite the 
newly installed LSA until. MinLSArrival seconds- 
have elapsed. 

The LSA installation process is discussed further in 

Section 

13.2. 

(e) Possibly acknowledge the receipt of the LSA by sending a 
Link State Acknowledgment packet back out the receiving 
interface. This is explained below in Section 13.5. 
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(f) If this new LSA indicates that it was originated by the 
receiving router itself (i.e., is considered a self- 
originated LSA) , the router must take special action. 



either 



updating the LSA or in some cases flushing it from the 

routing domain. For a description of how self-originated 
LSAs are detected and subsequently handled, see Section 
13.4. 

(6) Else, if there is an instance of the LSA on the sending 

neighbor's Link state request list, an error has occurred in the 
Database Exchange process. In this case, restart the Database 
Exchange process by generating the neighbor event BadLSReq for 
the sending neighbor and stop processing, the Link State Update 
packet. 



(7). Else, 
database 

copy (i.e., 



if the received LSA is the same instance as the 
neither one is more recent) the following two 



steps 

should be performed: 



(a) If: the LSA is listed in the r ■ u 

expecting ** reCeivi ^ ^ list 

an acknowledgment for this r« » t 

received LSA as an acknowLSent £v Sh ° Uld treat 

termed ^ "ate retransmit ftst 6 ™™ 9 ^ f ™° 

•implied acknowledgment- rt-«, 
ac.nowled^nt ££f ^' — e should be noted 

M process (Section 13 .5). 

(b) Possibly acknowledop t-K 

the databas^y^ «W » more recent . Jf 
has LS age equal to MaxAae snH „ 

«axSequence M umber. simply dlsca^ number equal to 
acknowledging it. (I„7hr s case the ?* iVed ^ A "itbouc 

a "on" ^T^.^ 

che State Update within the last M in_ rival . ~ " 



-.^ j. vax seconds. 

database codv bar-V 

be sent — ' " dCJCei: 



the 
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database copy of the i*<za 
(less -transmission list, and do £ SSSS£^ ^ 
recent) LSA instance. 

"•1. Determining „ hich LSA is newer 

h ^erminTwhLh"^^^ ^^s of an LSA, it Mt - 
when AS more recent. T >..c 11 

comparing a received LSA • ^curred, above 

comparison to database copy This " 

— procedure which 

An LSA is identified by i ts ,c> 

Advertising Router. For two fn^' Llnk State ID and 

— — . „ .... sr-zz M 3« - 



determine which instance is more recent: 



o The LSA having the newer LS sequence number is 

recent. 



sequence 



See Section 12.1.6 for an explanation of the LS 

number space. If both instances have the same LS sequence 
number, then: 

If the two instances have different LS checksums, then the 
instance having the larger LS checksum (when considered as a 
16-bit unsigned integer) is considered more recent. 

Else, if only one of the instances has its LS age field set 
to. MaxAge, the instance of age MaxAge is considered to be 

more recent. 

Else, if the LS age fields of the two instances differ by 
more than MaxAgeDiff . the instance having the smaller 
(younger) LS age is considered to be more recent. 

Else, the two instances are considered to be identical. 
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13.2. Installing LSAs in the database 

Installing a new LSA in the database, either as the result of 
flooding or a newly self-originated LSA, may cause the OSPF 
the r ° Uting table structure. to be recalculated. The contents of 

new LSA should be compared to the old instance, if present. 

there is no. difference, there is no need to recalculate the 
routing table. When comparing an LSA to its previous . 

instance, 

the following are all considered to be differences in contents, 
o The LSA's Options field has changed. 

o One of the LSA instances has LS age set to MaxAge, 

the other does not. 
o The length field in the LSA header has changed, 
o The body of the LSA (i.e., anything outside the 20- 



and 



byte 



LSA header) has changed. Note that this excludes changes 
in LS Sequence Number and LS Checksum. 



If the . contents are different- i-k^ p^n 



s 



Router-LSAs and networfc-LSAs 
with entlre r ° Uting table -»t be recalculated, starting 

it Ssski 2us."~ SJT ^ 

. n boundary routers may belong to 

the ^ ^"ently Providing the best route may force 

area* (19° " intra — route provided by a different 

Summary- I>SAs 

sundry- beSt r ° UCe t0 Che destination described by the 

necessary to re-examine all*^ the^eiter^l!^^ 

-° y Standards Track fPage 

° SPF Ve " io " ^ ^ x „ e 

AS-external-LSAs 

^base^en Is^a^ed " ^Id™ ?° 

retransmission- ■» ne^ors • ^s^S"^ 

lists (see Section 10) . 

13.3. Next step in the flooding procedure 

a:o d : d neW 'S so^ r s e e t re of nt) th SA hM - b — reCeiVed ' ifc -it be 
section S Set ° f the router -s interfaces. This 

included in this part o 1 Ifl 10n Usts - Als ° 

maintenance of the 'S^S^t^. 

( pt.thTrouter Sf'has ^T^^ ° f « « 

(see Section 12.4). originated 



perforn.^: sin^ for^exa^re P the e ^ ^ ^5f- » i s not 
fron. a neighbor and S i S ^ has not been received 

and therefore does: not need to be acknowledged) 

Depending upon Che LSA.'s LS tvoe f h» ,« „ w «?, ''• 

only certain interfaces. These ^1°°^^ W* 

following, are calledthe e^grble WfacesT 

AS-extemal-LSAs (LS Type = 5) 



The. eligible 



vTrtufrrin^^nd 1 ^ ""^r-s interfaces, excluding V 
Virtual links and those interfaces, attaching to stub areas. 
All other LS types 
(Area A) , ^he ^ .« *P^"ic to a single area 
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eligible interfaces are all »-w 

the Area A. xf £L A ,f ~ e ^ te f faCeS Caching to 

Area A iS the backbone, this includes 



all 



the 



virtual links. 



Link state databases must remain " V ' 

adjacencies associated vith^l s y^hronxzed over all 
This iated with the above eligible interfaces, 

is accomplished bv exemfin« / 
exigible, interface^ Its'houl"! ^J^TSLVT' 

decide not to flood an LSA out a n»^?^.i * fc thi ? Procedure may 
is a high probability that the at^aS^ ^ rface ' " there 
received che LSA. However in the^f neighbors have already 

procedure must be absolutely sure that^ne nef wJ 0 ^" 9 
do receive che LSA, so the LSA " t ll eventually 

U> ^ined^cVdeC^^ 

™. The ^ng ^-r^ed^ llt^SL™ 
~ . {a) If the neighbor i«; i„ ^ , 

Exchange, it y xs ln a lesser state than 

^la^exa^* ^ " 00di ^ neighbor 

<b L Exchange "'S^T'^SL^^JT ^ '-ighbor staCe 
Use associated wich this^?»; "V 11 " 6 re ^ esC 



that 



or * s copy : 

o If the new LSA is less recenfc then ^ 
neighbor . 

examine the. next neighbor. [20 J ^ lxst.Md 
° ^e S r ^ s r en -.-- tne ^ 
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neighbor, '"examin" **" **" WaS «*~ived fro. this 

the next neighbor. 

neighbor hit * At thiS P ° int we are positive that the 

^s^tSrsiaara?^ - - - - 

acknowledgment is seen fr^^^.^*^*** """^ 

new LSA out n ° W whether to flood the 

this interface Tf i n ku 

added to any of the statelet™ °" NOT 

X. no need to flood the ^ "STST^^^™,,. 
interface should be examined. 

If the new LSA was received on this in*- - 

was cn:LS interface, and it 

received the LSA already Therpf „ ro 

xnterface. Y ' Therefore, examine the next 

(4) If the new LSA was received „„ fl . 

interface state is Backup (i e the rout-- ^ face ' and the 
Backup Designated Router! examine ^ ^self is .the 

Designated Router will do'the^ V ° lnt "tace. The 

(i e ^ However, if the Desxgnate^out^f S£ 

the Backup Designated Router) ^ ^ retransoittin 

updates. 

W « ^is step is reached , the LSA musc be nooded ^ . 



the ^erface. Send a Link' State Update packet . <i„ cluding 
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: ; -drels S^ h X^ °— -e 

£c£ C s^^^^ 
adjacent neighbor "nicasts. to each 

^addresses for^^ecs are^ne^ hb^ 
addresses. P Cs are 1:116 neighbors' IP 

13.4, Receiving self-originated LSAs 

It is a common occurrence for a - . 

originated LSAs via the flLS* i recerve self- 

originated flooding procedure. A self- . 

LSA is detected when either 1) the L%'c 1A 
, equal to the router's own Router mJfSSii??**** 2 **-***** is 

„ - — ^ S t«. » s yiisfi. 

interface addresses., 
the HOW6Ver ' U " Ce - ed -X f -or ig inated LSA is newer than 

indicates that there are LSfls in Hho i- ^ such an LSA 
originated by the router before tSeT"? 
restarted. ore the last time it was 

origin,,:* . „.„ STtSS S tto S, " ™" 

network-LSA but the routp, f ' 2) the LSA is a 

the network or 3, the LSX is a net Desi ^ at ^ Router for 

is one of the rout er s own IP inter face State ID 

1P lnte rface addresses but whose 



ID Advertising; Router is. not equal to the router's own Router 

(this latter case should be rare, and it indicates that the 
router's Router ID has changed since originating the LSA) In 
all these cases, instead- of updating, the LSA, the LSA should be 
flushed from the routing domain by incrementing the received 

LSA's LS age to MaxAge and reflooding (see Section 14.1) 
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13.5. Sending Link State Acknowledgment packets, 

Each newly received LSA must be acknowledged. This is usually 

done by sending Link State Acknowledgment packets. 

However, 

acknowledgments, can also be accomplished implicitly by sending 
Link State Update packets {see step 7a of Section 13) . ' 

Many acknowledgments may be grouped together into a single Link 
State Acknowledgment packet. Such a packet is sent back out the 
interface which received the LSAs. The packet can be sent in 
one of two ways: delayed and sent on an interval timer or 

sent 

directly to a' particular neighbor. The particular 
acknowledgment strategy used depends on the circumstances 
surrounding the receipt of the LSA. 

Sending delayed acknowledgments accomplishes several 

things: 1) 

it facilitates the packaging of multiple acknowledgments in a 

single Link State Acknowledgment packet, 2) it enables a single 
Link State Acknowledgment packet to indicate acknowledgments to 
several neighbors at once (through multicasting) and 3) it 

randomizes the Link State Acknowledgment packets sent by the 
various routers attached to a common network. The fixed 

interval between a router ■ s delayed transmissions, must be short 
(less than Rxmtlnterval ) or needless retransmissions will ensue. 

Direct acknowledgments are sent directly to a particular 

neighbor in response to the receipt of duplicate LSAs. Direct 
acknowledgments are sent immediately when the duplicate is 
received. On multi-access networks, these acknowledgments are 
sent directly to the neighbor's IP address . 

The precise procedure for sending Link State Acknowledgment 
packets is described in Table 1-9. The circumstances 

surrounding 

the receipt of the LSA are listed in the left column. The 
acknowledgment action then taken is listed in one of the two 
right columns. This action depends -on the state of the 
concerned interface; interfaces in state Backup behave 

differently .from interfaces in all other states. Delayed 
acknowledgments must be\ delivered to all adjacent routers 
associated with the interface. On broadcast networks, this is 
accomplished by sending the delayed, Link State 



Acknqwl edgmen t 

packets 
used depends 



as multicast*. The DestinatW 



IP address 



Moy 

RFC 2328 



Standards Track 
OSPF Versions 



fPagne I5 2 j 
April 1998 




is 
recent 



LSA 
more 
sent. 

database copy, but 

back floo <*ed 
interface 0 " ******* 



than ^ sentTf aA Glayed ack- 

tisement received 

fron Designated 
Router, otherwise 
do nothing lse 




LSA 's ls -7 ___________ 

age is equal to lreCt acknowledge 

MaxAge, and there is Sent " 

no current instance 

of the LSA 

in the link state 

database, and none 

of routers neighbors 

are m states Exchange 



Direct acknowledg- 
ment sent. 
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or Loading (see 
Section 13, step 4). 



^ble 19; sending Unk stafce acknowledgeBi6nts 

or ° n the State o£ the interface. If the . H 

B *<*UP- thed 1 er ^ ace . state is DR 

broadcast'**' «~ -'^22 s^ *" <>tW 

networks, delaye d Link _ ^ ^ * non " 

^"^at^ Sendi " 9 "* Packets as ^ 

Network m 7t ? ■ Router RT4 Designated 

These ' xt 1S received by routers ^ a ^ to 

routers will n „„ „ ' *** «T3. 

still 111 not f lood the LSA back ™- 

-st ensure that thai i • 
waiting the ^ ««~* - ign ^; s State *2tS« ~* synchronic 

The reason that th » u "leasts, 
slightly different- ; f^nowledgment l ogic fo _ _ . 

13-6. Retransmitting lsas 
LSAs flooded out an adW 

" X£ fch J-s xs set 

• Moy . 
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Several retransmitted LSAs may fit into a single Link 

State ...... 

Update packet. When^ LSAs are to be retransmitted, only the 
number fitting in a single Link State Update packet should be 

sent. Another packet of retransmissions can be sent whenever 
some of the LSAs are acknowledged, or on the next firing of 

the • ; • . ' 

retransmission timer. 

Link State Update Packets carrying retransmissions are always 
sent directly to the neighbor. On multi-access networks; this 
means that retransmissions are sent directly to the, neighbor 's 
IP address. Bach LSA^s LS age must be incremented by 
InfTransDelay (which must be >>■ 0) when it is copied into; the 
outgoing Link State Update packet- (until the tS age field- 
reaches the maximum value of MaxAge) J . 

If an adjacent router goes down, retransmissions may occur until 
the adjacency is destroyed by OSPF' s Hello Protocol . When the 
adjacency is. destroyed, the Link state retransmission list is 
cleared.. 



13.7, Receiving link state acknowledgments 

Many consistency checks have been made on a received Link State 
Acknowledgment, packet before it is handed to the flooding 

procedure. In particular, it has been associated with a 
particular neighbor. If this neighbor is in a lesser state than 
Exchange, the Link State Acknowledgment packet is discarded. 

Otherwise, for each acknowledgment in the Link State 
Acknowledgment packet, the following steps are performed: 

o Does the LSA acknowledged have an instance: oh: the Link state 
retransmission list for the neighbor? If not, examine the 

next acknowledgment. Otherwise r 
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o If the acknowledgment is for the same instance that is 
contained on the list, remove the item from the list and 
examine the next acknowledgment. Otherwise: 

o Log the questionable acknowledgment, and examine the next 

one . 



14. Aging The Link State Database 



Each LSA has an LS age field. The LS age is expressed in seconds. 
An LSA ' s LS age field is incremented while it is contained in a 



IS 

LSAs 
As 

LSA 



incremented ^ by Inf TransDelay . 

An LSA-s LS age is never incremented past the value MaxAge 
having age MaxAge are not used in the routing tatrte calculation 

time, the router must attempt to flush the 
from the routing domain Thi « i « *~ • „ 
MaxAge LSA just as if it SUBpl * ^ "flooding the 

13 .3) . , 1C * aS a newl y ""grated I^A (see Section 

When creating a Database summary list frr » , c 
to thT MaXA9e LSAs. present in^LT * SSST^TSSi 

Section io.3 for more details 

^^h^^ 3 ^^ S^^t^^JT ^ ^—'-li- 
the ne r^^ ink S — — mission ^^^0^^ ^ ~ 
neighbors are in states Exchange or Loading. 
When, in the process of aging the link «t-**- 

age hits a multiple of rh^vl * datai>as e, an.LSA's LS 

verified. "xtipie of CheckAge. its LS checksum should be 

If the LS checksum is incorrprf ^ ^ 

detected, and at the ve^y 1 eas t tL ^ ^ or . me ° or y error has been 
restarted. ery least the router itself should be 
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14-1- Premature aging of LSAs 

2ge L co ^.^^^^^^^ ^-tting its LS 
then reflooding the LSA * I sequence number alone, and 

Exchange or Loading. We call the .^ e ^ hbor % a " in states 
MaxAge -premature aging-. reccing of an LSA's LS age to 

.... Pr . eraature aging is used when it • _ • 

originated wneru lt: " - time for "a self- 



LSA's sequence number field to wran at- <-».{» 

LSA instance (having LS secuenr-^, w P °* nt * ^ current 

x^.i.o tor more information . 

Premature aging can also be used when, f or examnU e 

router's previously advertised "^1 ror exanple, one of the 

reachable. In thxl c rant:** i s no longer 
external-LSA from ^^S^SL^* ^ fl " Sh itS AS ~ 

procedure is pref erabl e °to^^ ^ 

m etric°: r ?inate 3 T 

unexpect^'^' ^ be .used when 

(s^'sec?!:: 1 ^^!^^^ 5 LSAS dBrl * ^ fl ° odi »* P-cedure 

originated by other rovers to ^ - ^ be «" 

originated when either U tnt LSA^t^^ ^^ered self- 
equal • X) tne ^ s Advertising Router is 

to the router's own Router ID or 21 t-K~ t ck ■ • 

its Link state ID is equal o on^ o f f ^ " a netwrk "^ and 
interface addresses . ^ rout ***s own IP 
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15. Virtual Links 

. The single backbone area ( a rp -. Tn n „ ' 

disconnected, (Area ID = 0.0.0.0) cannot be 

or some areas of the Autonomous System will h«-« m 

establish/maintain connectivity of h! L unreachable . To 

be configured through non-blckbonf *~ backb °ne, virtual links can 
connect physically separate cL** i "l*^ linkS Serve to 

endpoints of a visual Unk are ? k °5 ^ backb ™*- *he two 

virtual are area. border routers. The 

link must be configured in both routers Th« 
information in each rm^ B / configuration 

endpoint router consists of the other virtual 

(the other area border router \ ^ 

routers have in cordon (caned^Tra^f,™""^ 0 " 6 the two 

cannot be conjured through J^^^** ""«» 

The virtual link is t->-« *- j 

unnumbered point-to- a:ed as if it were an 

point network belonging to the barvv^ ' j • ' 
two area Backbone and joining the 



border routers. An attempt 
an adjacency over Mde to establish 

virtual v " tual link, "hen this adjacency is established the 

i^^^t^^^^. r os PP Pac)cets 

In each endpoint routpr ►->* 

^discovered by exan^^^uS^r^ 1 *** ° f the vi "ual link 
. endpoant router. (The entry's a S^ f ° r the oth « 

configured Transit area) .. \V ™ area «use be the, 
corresponding routing table- '"ff 11 ^ -virtual link's 
occurs for , entr *- The InterfaceOp event 

becomes™* Whe " itS —espdnding routing table ^ 

when^ 1516 - tersely. the Inte rf aceDown ^ 
routing table entry become-: 

virtual link's viability ^s ^^habl*. In other words, the 

mtra-area path, through the ■ TrJZt??*** the ^"tence of ^ 
endpoints. No te thai a vir t^aT^v * ' between the two 

virtual lank whose underlying path has 

greater than hexadecimal Oxffff 

cost in a router-LSA) should be c^ ^ ^ X1 ? 1B, size " f *" interface . 
treated the same as It • S^SW «^ 

other details concerning virtual lin ks are as follws= 



cost 



The 
o 



AS-external-LSAs are NEVER n rt ^ . 
. -is would be ^iJ^^^r^^ J*-^, 

Moy 
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external -LSAs are alrea^ , , 

summarized over virtual 
Database Exchange f ad ^cenc les during the 

process . 

o The cost of a virtual • 

be the cost of^he^ntra^rea 5 ^S^^u " " "> 
border routers. This colt appear^r^ ^ tW ° def ining area 
corresponding routing table ent™ w£ h f virtual link's 
link changes; a new router^shouTdV 116 C ° St ° f a 
backbone area. aA snould be originated for the 

o Just as the i ■ . 

by eh 3 C ° St and ^ ity are determined 

the routing table build process u 
^ routin, table entry for ^ o^Zot^T^ ^ ^ 

interface address Fnr *-u~ 

neighbor's IP a^es" ^-e and the virtual 

6 are used w ^en sending OSPF 



protocol packets over the v irt-,, a i i - » 

both) of the virtual link l^TiLl "° t& that " hen (or 

via a* unnumbered point-to^ B JLTT1?h^ * Mt 5 ~ 
calculate either, the virtual ! . ^ be possible to 

■ . virtual neighbor 's "^^2*^^" *»~ -d/or the 

l ^ Wlress ' thereby causing the virtual 

to- fail. - 

Unk O in each endpoinfs router-LSA for ^ the 

is represented as a Type 4 link, : ■ v. 

virtual neighbor'fosPP l ut 10 is Vet to the 

to Houter ID and whose Link Data is> set 

more t ' le virtual interface ' s . IP address . See Section 12 . 41 for 

information. 



con^r^Tftransi Z^^* i- 
^ansit. area for one'cr' ^ ^^^^ ^ 

area ll^^ 1 ^ ^ S ^ns S and 16 .r, . ^ ^ 

special treatment when summarizino wvk« 

i:ctior tion 16 i2 3f; 3 '- - -as * 

° ajS^Sr: ^^«--ff*«. H-tmterval. is 
expected round-trip delay between thftwo^outers* 
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on the hard ^ eSti — * Virtual link.- it is betCer ^ _ 

side of making it too large. 



16. Calculation of the routing 



table 

ScKTS^SS st a e t° S da F ta r b Utin? table cai -^tion. Using its 
following algorith^ ^"SlJ t ?S"o«?iiT£i * XWXtW ™* ^ 
each step, the router must acr»«f C "^ 1 ?? table st ep by step. At 
state databases (e o a „ ce ss individual pieces of the link 
certain router)' ' rouCer -^ s A originated by llnk 

Section 5 aCCSSS iS P " £ °™^ * loo kU p function discussed in 

co 12-2. The lookup process may return an LSA whose LS age is eq ual 
MaxAge. Such an LSA should „„, K „ 

calculation, and is treated ?°st * rOUtin 9 tabl * 

had 3USt as the. lookup process 

failed.- 



. The 

11. 



OSPF routing table's organization is explained in- Section 
are ^presenteHn* 3 ^ ^ ***** ^ Process 

LaSif " 3 • Pr ° CeSS be b - ke " -to the 

. s ID The present routing table is invalidated. The routing table 

that^nges^r ^"tSg ""^ ^ " -~ * S ° 

routing table entries can be identified. 

shortest- intra " area are calculated by building the 

Gentries whose^s t^jon* " ^ 
router" are Type- is "area border 

calculated in this step. This st P n i« ' ' ^ . 

At first the tree is constr^Jt h5 i descr:Lbed two parts, 
between routers Ind tr^^T ^ c ?^^in S those links 

networks nd transit networks. Then the stub 

are incorporated into the tree r>»»^«~ -k 

path e - During the area's shortest- 

^^^L^-^S^T^^ is also 

(3) The inter-area routes are calmUfo^ *-v 

summary-LSAs. If the router Is , through examination of 

(i.e.. it is an a rL h! f attached to multiple areas 

are examined WdGr router > ' only backbone summary-LSAs 
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area! 4 ' b ° rder route " connecting to one or more transit 

(i.e, non-backbone areas whosp T r ^d • , • 

TRUE) , the transit areas • su^a^As *5 found to 

whether better oath.! 0 !rT^- S t are cammed to see 

found in Stepf 2 3 above. ""^ Ch& transit areas th *» "ere 

calculated. through' 0 6Xternal are 

been determined 'In ^"f-r ^ AS " eXternal - LSAs) . ^e 

Steps 2-5 are explained in further detail below. 
Chaqges made to routing table pni-ri. 

calculations can cause the OSPF "f ! ° f these 

For example, a change to an L ' t0 take further actions. 

border router to origi^L new ^ r ° Ute Wil1 cause ™ "ea 

•----reEtio-n-^-foT^mplete^- 8 ^^ 

-List of the OSPF protocol 



actions 

resulting from routing table changes. 

16. 1. Calculating the short est. path tree for an area 

This calculation yields Che spf ~e ■ J ' 

associated . * et <>£ mtra-area routes 

calces the '""^ h ^"eri Area A,, A ' router 

o^thrsh^Lt^arh^erL^aone T ^ r0Ot • l22, 
first, stage, only Jinxs^ween rovers ^V"**' ^ the 

networks are • . routers and transit 

fro, C ° nsid « ed - the Di jkstra algorithm, a tree is formed 

stage. SUbSGt °* the Un * Sta ** ^abase. i„ the seC ond 
stub «e added to the tree by considering the link* to 

networks . 

The procedure will be eamVain^. • 
that explained us xng the graph terminology 

was introduced in Section o t>w~ 

represented as a directed oraJ * "»* State database is 
routers, transit networks ™d ; k ^ aph s vertices are 

networks and stub networks. The first stage 

the procedure concerns only the transit vertices ( routers 

-o^ t Path^l^^ , ^ 

with each transit vertex: ^ allowing data is also associated 



•of 
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Vertex (node) ID 
type (router 2 "^' her with the vertex 

or network) uniquely identifies the vertex 

vertices the Vertex rn i c t-v>. ^ vertex. p or rou ter 

network vertices' it L^he ° SPF "° Uter ID " 

Designated Router. address ■ «* the network's! 



An LSA 



Each transit vertex has an associate r c» 
vertices, this is a wute-m J ► ■ r ° Uter 
is a necwork-LSA (which " actuallv ^ networks ' this 

network's Designated Routerf rn^ °"gmated by the 
. State ID is always 1 „ ^ any case, the LSA's Link 
ys e^al to the above Vertex ID. 

List of next hops 

paths . USt ° E next h °P= the current set of shortest 

shortest p'athVduet thfe" ^ ~ 

P ens due to the equal-cost multipath capability. 



Each next hop indicates the outgoing router interface to 

Po\ e nt- f ^iL l t nt f fn d ^ e ^»^ E~~ <' 

includes the IP address of the nexc r^ter^f * P , 

path towards the destination. Ut ^ ln Che 

Distance from root 

fro'™ the'root^rS,: 0 ^^' ° f *» ths 

is calculated as the sZ^Tt the ctsts"! °lS **** 

constituent links (as arl»»^i^ S ■ of the path's 

network-LSAs, . toe ^1^,7™^ 
another if it has a seller 55 s'tate 

r ^ St "^^ed P ar^ ow i i At'ea^ ° c jkSt " 
algorithm, there is a list of each iteration of the 

necessarily^ ^ ^ ^e^* "not* 

th h : t S L 0rteSt c ^s e e S t H °^o er thf root^ " ^ — *^ vertex 
shortest; this to the root are guaranteed to be 

Possible action to^, 1 c^'3^rSSL^,Sr^^ 
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RFC 2328 OSPP Version 2 April 199fl 

candidate 0 """" ^ ite " teS again " It terminates when the 

list becomes empty. * 

database. 

U) IT ^t^^ lta ^ "ear the list 

. only the root (which is th« short est-path tree to 

Set Area A's TrLsUCapabilit^to^ALSE 9 ■ 

<2> the" t \sTa t ssocia S t ed d w^h t ver^ t v ee tT"* 

Area a-, link state databa'sVbased on the Vertex ^ 
this is a router-LSA an* k;,. t, * i vertex ID. If 

. Section A. 4 2) L set 1 V ? £ Che rout «-LSA (see 
TRUE . m any^aL eacrii^L S Kj ranSitCaPabUit ^ to 
cost to an adjacent vertex £r ff h*/ 116 9lVeS the 

it joins vertex V to vertex W f? describe <* "n*. (say 

(.a) I-£— frhi-s- 



±s-a TOW-fco a stub network. examine"^ 



next 



iink in ■ V*s LSA L' lc 

considered in the seconds tao^/^ u networ * s will be 
calculation. ge ° f the shortest path 

t b ) . Otherwise, W is a *->-=~ 

network,. L ook UP ^ ' « transit 

network-LSA) in Area A s liS - ^ <router-LSA or 
LSA does not exist or xts ts^at ********* Xf the 

it does not have a link tec./to'' 3 " *° °* 

. tack to vertex V, examine 

next lirik in. Vs LSA. [23] 

l« ,„. „„» „„. co „ „ of r „„ lelna 

from the root to vertex W n -~ i 

link state cost of the ialr^A ^" , t0 the sum of fc he 
path to vertex v ani ^ ^ • ralculated > shortest 

between verti^^f^ adv ^^ co St of the iLk 

■ Moy • 
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that already 

the candidate Ust. then exa^ne the 

-suit from winTST^J^ ~ «*« 
this calculation is the aZZZt ?• Input to 

parent (V). ?his ^ < w > • and it s 

16.1.1. This sit of hoS In/f ShOW " in Sec tion 
next hop values that appear ^ w ""^ t0 the 

list: appear f °r W on the candidate 

. ° Less than the value »-l,_>. 

candidate lilt or if W do^T^ Wrtex W ■» the 
candidate list then set 2°. * > aEPear on the 
candidate listVn ™. e " try for w on the 

root . Also ^calculf celhe V^T* ° f ° f the 
result from usin^: that 
next hop values for W accord? set ting the 

in section £ ilser!^^ ™e next hop 



(3) If at 



. it takes 

as .nput the des t i„ ation , w) ifcs parent 



^tSS'c'S'L 2^2£ftj.i«. ^ ty. the shortest- 
and this stage- of the n^L been completely built 

choose the vertex belongtng t^t™™?? ' Otherwise 

closest to the root, ana add it to J c annidate list that is 



that when there * ^ ■ 
rO0t " net fc 3 Ch ° 1Ce ° £ closest to the 

consistent with the tie-breaker^ ^° SC PaChs ' Th " " 

routing m ° dlfled °- k -ra algoritT in the 

^ s Multicast 
extensions (MOSPF) . 

(4 ) Possibly modi fv i-k« 
table Y modif y the routing table 

entries modified the as ■ r ° Utin9 
path tvp"; wilYbr^^ «r Wil1 ^ Set to *"a A 
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If the newly added vertex ± s 

boundary router, a routino b ° rdei " route ^ or AS 

destination type is"^^ whose 

the * hS °P tlon ^ field found 

the en dpomt of one of 
the virtual r °"ter-s virtU al links; and 

uTS ""-^tt'^SLKs^ - --- 



the IP 



shortest- 



Router X- s interface address IT S address is -t to 
-uter- LSA) that point s e ba S c) [ C ° o nta ne e r d o ^ £ 

h"?'" f^alently. 



back to Router x*s narL 1S the in terface that • . 

to *\ss£sr^r^^£-. si- 

the ""•<■ -««. 1. . „», lt 

table entry f or the 



its 



— x XO « 5 wich 

net^rk-LSAf Ubn rf HT" ' f ° Wd in <=ha body of the • 
(i e Vk ■ Cne ro "ting table p„; ° , ass °ciated 

. < le ; . there ls already an int-^T Cry alr *ady exists 

destination installed in route t° the 

exa mple . VSrCiCeS ha - ~PP.d to" the" 6 T^^ 1 ^^ 

established^^* ^ D ^- d * ^ ^ 

the current routing table 



entry 

should be overwritten if anrt nnlv it »-u 

dust as short ana the current^ ng^ble^S" f ^x 

"uncase? a^outiPa^ab^ 16 f ° r th * network « 

be added. The rou no tab^ eI \ tr V° r .^ XP network should 

should be se^.o^-nrnew^^ddene^e^^" 6 
(5) Iterate che algorithm by returning to Step 2. 
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The stub networks are added to the tree in 

second stage. In this staap ° , r f e ln the Procedure -s 
examined. 9 Those that have^en "TJ* Ve "i ces •« again 
in Ve Deen determined to be unreachable 

vertexTalTi, $?" t ™ , P ° r ~* "achabie .outer 

the Ctle associated router-LSA is found in 

link state database. Hachstub network link appearing in 

LSA is then examined, and the following steps are executed: 
(1) Calculate the distance D of — 1. 

is equal to the distance from th" """"^ fr ° m the root - ° 

(calculated in stage ™ plus the '° Che r ° Uter verte * 

advertised cost. CoLare'tnT* V t " b networl < ^"k's 

cost to the stub network ?hf n r t0 the CUrrent best 

stub network's current to„H„„ 6 by lookin Ef "P the 

calculated distance D is 6 ^ " the 

stub network link in the LSA exam ine the next 

entr^Ls^L^^^-c-L-te " Y~"- 

would result from using the ^, k ! °, f nSXt h °P s that 

calculation is shown'in Section 16 ™ S 
calculation is the a e<5 M„»F - t : lnput to this 

parent vertex U^lotlllT^Z s^"^ 10 Md the 

the x vercex ' ■ If the distance D is 

same as the current • 
this set current routing table cost, simply add 

of next hops to the routino K aK1fl 
hops. Ling table entry's list of next 

5?i5S" c ;r as.'sS'i sis*,- ■ u » «•» 
£S=i= l. i;-'»i- e - »« s -s-j.^ 



routing table entry's cost to D, and by setting 
the entry's 

list of next hops to the newly calculated set. Set the 
routing table entry's Link State Origin to V s router-LSA. 
Then go on to examine the next stub network link. 

For all routing table entries added / modi fied in " the 

second 

stage, the associated area will be set to Area A and the path 

type will be set to intra-area. When the list of reachable 

router-LSAs is exhausted, the second stage is completed. At 
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this time, all intra-area routes' associated with Area A have 
been determined. 

The specification does not require that the above two stage 
method be used to calculate the shortest path tree. However, 

another algorithm is used, an identical tree must be 

produced . 

For this reason, it is important to note that links between 
transit vertices must be bidirectional in order to be 

included 

in the above tree. rt should also be mentioned that more 
efficient algorithms exist for calculating the tree,- for 
example, the incremental SPF algorithm described in [Refl] . 

16-1-1- The next hop calculation 

This section explains how to calculate the current set of 
next hops to use for a destination. Each next hop consists 
of the outgoing interface to use in forwarding packets to 
the destination together with the IP address of the next 

hop 

router (if any). The next hop calculation is invoked each 
time a shorter path to the destination is discovered. This 
can happen in either stage of the shortest-path tree 

calculation (see Section 16.1). In stage 1 of the 

shortest-path tree calculation a shorter path is found as 
the destination is added to the candidate list, or when 

the 

destination's entry on the candidate list is modified (Step 

* d of sta 9 e !> - I" stage 2 a shorter path is 

discovered - 

each time the destination's . routing table entry is 



modified 



may be 



(Step 2 of Stage 2) . 

The set of next hops to use for the destination 

recalculated several times during the shortest-path tree 
calculation, as shorter and shorter paths are 



discovered . 

shortest path(s) P resulting from the absolute 

KL^t^tSTcSS'^ iS «» «» ^stiaation ana 
(the calculating router) and the ■ ■ """^ the "> 0t 

always a transit vertex (H al^ ' 10 "- The P arent is 

a transit . |le ' always a router or 

network) . 
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current " " leaSt ° ne intervening router in che 

SSESElST Srinh'e^^f^th' 00 "* ^ ™- 
from the PXy lnheri ts the set of next hops 

itself). This means that £h» 2 .. the . calcu ^ting router 
. directly connected network or dlf ^f"" " either 

The outgoing interface in Sf! * ConnecCed router, 

interface connecting to the destf^ • " the 0SPF 

the destination is a router whfrh " neC «°rk/router ■ If 

calculating router via f - * connects to the 

destination's ne hop p a fc °"f UUiPoint network, the 
examining the destination's ^ deC ermined by 

fieia back to the calculating router'an^ng 

dxrectly connected network „5 destination is a 

the calculating router 'via a oofn^ " ? hi< * to 

no u ouce r via a point-to-point interface, 

next hop IP address ; «. • 

destination is a S 13 required. If the 

router connected to the calnil»n~. 

link, the setting of the next hoo ^"V" 3 virtual 

the calculation in Section 16. : I "" ^ deferred UnCil 

aLec^irc^nnectrthe^rcuratinl^-t- 3 ~ «»' 

S^i^S^ ^ ^ - -eL^by 1 — 

the -ter-Cirtha °" points^cTto^th ^ " 

the pomes back to the parent network, 

^ link's Link Data f ield provides fche „ ^ ^ 



next 



router. The outgoinq in ter f. ro ■ - 

from the next hop IP address (or L" 5 " then be d ^ived 

the parent network) Can be ln herited from 



16.2. Calculating the inter-area 



routes 



backbone summary-LSAs are ex S » multiple areas. only 
single area examine that area s ^ att * ch *d to a * 

link state database (call it Area A) 

Moy 
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J^^in^ft^^aa^^ — — rs. Each 
destination described by a summary LSA — that the 

LSA. waxAge, then examine the the next 



router 



(2, If.^LSA was originated by ^ calculating 
examine the next LSA. 



(3) If it is a Type 3 summary-LSA a ^ „ k 

destinations described bv th^' he coUe otion of 

router's conf i*uJ^J?J£j£™^ one of the 

a "d the particular area * Secti °» 3.5). 

summary-LSA should be Ignored ?A^ n9e . iS aCtive < then the 

^ai„en n °th-^ 

LSA . s '« ^^.r^^J^^J^^ 
Link State ID with 

body of the LSA), ^"^f 5 MSk Gained in the 

- associ at ed area. If no such ^ ^ ^ ^ 

(i.e., BR is unreachable in 

LSA and consider A ^ea A) do nothing with this 

describes an inter-area pa T t d h Else < this LSA 

-e distance to BR P ? M %» £ t ^~ * --co, is 

the -st of chis inter . area path 

f table entry associated with Area A) rE no 

if the entry's hh -try exists 

-try s path, type is -type l external" or 



BR 



Call 



the 



"type 
list 

Moy 



2 external-, then install the int^ 

associate, area Area A , ^1^^^^ £ gth 
of ne XC hops to router br, and Advertlsing roufcer 
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<6) 2£. fc^tffi^ErS t table «. intra-area 

preferred) . ° " the Untra-area paths are always 

(?) "^-a^^^Lix £ r ° Uti - «*• «• also 

»« .f patKs that ^^^T^il. - - 

16.3. Examining transit ar^c 

1C areas summary-LSAs 

p^i'-S^SS^ ^at a""" — — c hed to 
areas U~ £ carry!*, 

-Toi^^^^^r^:: s - ion a- - - TR0E in step s 2 e of 

S^-V^'S^JS^ * - «— • -e tra nsit 
than the paths previously allauttttT in^T <Short -) Paths 
prev^us,/^^ f ° Und th - are betted ^ ^"^f * 16 2 - 

diSC ° Vered PaChS i„ the routing taMe 

chos - c alculation alsQ determi _ ^ _ _ 

a ^^a-"" h ° P - oalculatea as 

Sections 16.1 and 16 2 Afc»,- 

below, any paths calculated in sect^" 0 " ° f the calculation 

7 unresolved — --"ops 2 S hL 6 id t?£Z2? 

ST- C ^ «. eS^^r^T *» -ansit areas ■ 

describes a route th " t Each such sunvnary-LSA 

(Ms address is obtained b \ rM * C ° a Netw °rk N 

the network/subnet mask contain H ^ ^ LSA ' S Lin * State ID with 
the case of a Type , su ^ y !^f « the body of the LSA) or in ' 
Suppose aIso chat ch to an AS boundary router N 

border router BR. "™nary-LSA was originated by an area 
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(2) If the summary-LSA was originated by the calculating router 
itself, examine the next LSA. 

(3) Look up the routing table entry for N. (If N is an AS 
boundary router, look up the -router" routing table entrv 

if S the a r ST baCkb ° ne arSa) • " ifc d ° es ~t exists 

if the route type is other than intra-area or inter-area, or 

the a b! a kb„n SSOClated . With tHe r ° Utin9 table entr V ^ not 
% b ackbone «ea, then examine the next LSA. In other 

rlltl: f * .^l^tion only updates backbone intra-area 
Section 16 n 2. ln ^ inte — found in 

(4) Look up the routing table entry for the 
advertising router . 

examine ^ aSS ° Ciated with the A. If it is unreachable. 

sum "fL tSA ' Otherwise, the cost to destination N is the 

- ^it£i«r n \z -L- Area cLrthi s 3 cos bl ?A? nt - and the 

(5) If this cost is less than the cost occurring in 
N s routing 

for 16 '"Bp 7 ' °X erWrite N ' s list of next hops with those used 
Else, if IAC set Ws routing table cost to IAC. 

to N h s li = t 'J N ' S current cost - a ** BR-s list of next hops 
associated ' ° f h ° PS - In ^ case < C he 

N S ^° Uti 2? table entry must remain the backbone area 
and the path type (either intra-area or inter-area^ Zkt 

also remain the same. ' c 

makes " " imp ° rtant to note that the above calculation never 

potentially 011 ^^ deStinations reachable, but instead jusC 

finds better paths to already reachable destinations The 
calculation installs any better cost found into the routing 

to other areas ^ " ^ ^ ™ surmaary-LSAs * 

As an example of the calculation, consider the Autonomous System 

" " f lg " re . 17 ; There is a si "9 le non-backbone area 

pieces To P main^ lly ^ baCkb °" e int ° tw ° se P a "te 

virtual link' ^"tain connectivity of the backbone, a 

side b oT C ° n ltT r f ed betW M e " r ° UterS RT1 and RT4 - 0n the" right 
rinfrJ 1 th * flgUr6 ' Networ k Nl belongs to the backbone. The 
dotted lines indicate that there is a much shorter intra-area 
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Area 1 (transit) . + 

— + 1 1+— +100 ! 

|RT2|— — | RT4 | =-==^~=L= I 

1/ + + ********* + + . j 1 

l/*Virtual ! 
Link I 

=== = === | rti I * * Net | work 

+ — - + \ " | Ml 



\ 

+ 1 1 + - — +20 | 
|RT3| |RT5|=i= 



+ + 



I 



Figure 17: Routing through transit areas 
backbone path between router rts »t .. 

eoth there is between -Router R^anT » '^LlV^o? 

Nl U L e to RT4 TreTT r — ry-uSAs for Network 

£cZL£\?ZcTo- n P lt\ tl ? f b6en Elated for the 
link, will ha" calculated U a e Lth 1 t>! left v, end ° E the vi "ual 
data traffic destined for Network m ^T 3 * RT4 for 

is so much closer to Network m „n ' SinCe HouCe ^ «HS 

(e.g.. Routers RT2 and Rrafwui f orwfrrf ■ ihterna * to Area 1 
traffic towards t ' forward their Network Nl 

And indeed. after Router RT5, instead of RT4 . 

examining Area l's summary-LSAs h„ -v. u 

Router ary ^As by the above calculation. 

RTI will also forward Network mi lect- 
in this example the virJ ? f II towards RT5 . Note that 
traffic to P the Vlr tual U„k enables transit data 
be forwarded through Area 1 h,.* ,-u 

data traffic takes does not' follow h ^ aCtUal ^ ath ^he transit 
words, virtual links allow transit ^ e J lrtUal In other 

through an area but do trafflc to be forwarded 

that the Sa ' bUt do not dictate the precise path 

traffic will take. 
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16.4. Calculating AS external routes 



each of che AS-external-LSA<: examini "9 AS-external-LSAs 

external -lsas describe rout« ? " consi <^ed in turn Mo^f L 
AS- external -LSA can .Co S^riS**^ IP d -tinations 
Autonomous System (Destinat?™ J a defa "lt route for the 
network/subnet mas, = ^000000 of = £ f ™ la >*?"™^ 

UO). For each AS-extemal-LSA: 

;;; ^ » ™ 

rout J itself^ * the calculating 

examine the next LSA. 

(3) Call the destination describe k . 

obtained by masking ^"^fj^ th f. ^ N. N > s address 
network/subnet mask contained if t L ^ State ID the 
up the routing table entries .n^ f-^ ° f the LSA • Look 
area) for the AS bounda^J^^ "™ Per attached 
" If no entries exist for rl ' that ori 9inated the 

unreachable), do nothi™ u router ASBR (i. e . AsB r ; «f 
next do nothxng with this LSA and consider 

in the list. ^ 

destination 13 " ^ "» — an As ^ ^ 

the AS-" the forwarding address 

external-LSA. Thi<; ; n ^- . 

If the forwarding address .00- 

„ bl . - « „ «. « t -r - a - 

entries for the a<:rh , 
follows. the ASBR - »•!•<* the preferred entry 

« -ClSS3Com P atibi lity is set Cq 



as 
set 



" » fa une the 

table entries, select^ rou^teM fining routing 
cost,- when there are multinl» i le entr * wit « the least 

ospp -tr.es the entry who^L^^ areThaT^^' 

Area 10 (when considered as . 

chosen. an unsigned 32-bit integer, is 
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If the forwarding address io 



(4) Let X be the cost specified by the preferred routing table 
entry for the ASBR/ forwarding address, and Y the cost 
specified in the LSA. X is in terms of the link state 
metric, and Y is a type 1 or 2 external metric. 

(5) Look up the routing table entry for the 
destination N. If 

no entry exists for N, install the AS external path to N, 

with next hop equal to the list of next hops to the * 
forwarding address, and advertising router equal to ASBR. 
If the external metric type is 1, then the path-type is 

to type 1 external and the cost is equal to X+Y. If the 
external metric type is 2, the path- type is set to type 2 
external, the link state component of the route's cost is X, 
and the type 2 cost is Y. 

(6) Compare the AS external . path described by the LSA with the 
existing paths in N's routing table entry, as follows. If 
the new path is preferred, it replaces the present paths 

N's routing table entry. If the new path is of equal 

preference, it is added to N's routing table entry's list of 
paths . 



set 



preferred 



<a) Intra-area and inter-area paths are always 

over AS external paths. 



(b) Type 1 external paths are always preferred 
over type 2 

external paths. When all paths are type 2 external 
paths, the paths with the smallest advertised, type 2 
metric are always preferred. 

(c) If the new AS external path is still indistinguishable 
from the current paths in the N's routing table entry, 

and RFC15 83Compatibility is set to "disabled-, select 

the preferred paths based on the intra-AS paths to the 
ASBR/ forwarding addresses, as specified in Section 
16 .4.1. 
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(d) If the new AS external path is still indistinguishable 

from the current paths in the N's routing table entry, 
select the preferred path based on a least cost 

comparison. Type 1 external paths are compared by 
looking at the sum of the distance to the forwarding 

address and the advertised type 1 metric (X+Y) 

Type 2 

external paths advertising equal type 2 metrics are 
compared by looking at the distance to the forwarding 
addresses . 



16.4.1. External path preferences 

ASBRs/fordfH intr ^ AS P " hS " e -v-ilabie to 
ftbBHs/torwarding addresses f„n„ ■ 

which paths are preferred Th«» followln ? rules indicate 

ASBR is reachable through multiple Trill * Pply th * "me 

same ASBR, whi e^X^tLVthY^rh ^ ^ 

separate ASBRs/ forwarding addresses^In'eit^r" 3 ^ ^ k 

EK^ a sepa " ce ^ 2S. c S y T 

to hi Mi:abie°d-° nly aPPUeS WhSn ^1583Compatibility is set 

P^ferencT P a r re e aTfo e ilows leS ' N o S t t e at i t fr0m C ° ^ 

rules, there may still be ? hat aS a res "lt of these 

preference. ™n * ^ f P ' path = of the highest 

determined case ' the Path to use must be 

based on cost, as described in Section 16.4. 

° mos'rp""^ 8 USlnS n ° n - baCkb0ne a — always the 

16.5. Incremental updates - summary-LSAs 

When a new summary-LSA is received it i<= ^ 

recalculate the entire routing*^; "cSJ thT^^stination 

Standards Track fPage m) 

° SPF Versi °" 2 
described by the summary-LSA n /■«■.= =/m 

masking the LSA . S Link State ID ttSlZ iS ° btained by 

contained in the body of the LSA) and 1 t ? netW ° rk/s "°^ mask 
which the LSA belongs. There are then V ^ A be the area to 

y mere are then two separate cases: 

area ^ ^ . ' *"* A iS the back *°ne and/or the router is not an 
border router 

performed.'" CaSS ' ^ Eoll °-^ calculations must be 

ae^inatLn^",^.^^ V? '° _ ^ 

saving the entry's a r / ^ 13 lnvaiid ^ed, 

■ calculation in Section 1 fi 7 comparisons. Then the 

destination N . In this calcuiaH t?"? ^ the Si "* le 

summary-LSAs that describe alculatlon ' al * of Area A's 
addition, if the router it w° N " e exa ™^d. In 

or more transit ^'f r ° Uter attached t0 

Section 16.3 transit areas, the calculation in 

must be run again for the single destination. rf the 



an e %1 t Lu°naa r h rr e o u C ^ r CU | a a s ti r^ a b V : cos t/path to 

summary-LSA) or to any forwa^f ^ case- for a Tyoe 4 
external-LSAs will h^e to be ~! addre r eS ' a11 
newly "^"i- in 8« t i^ r, ^^»*^ ? the 

' N as now- 

unreachable, the calcic' 

route to N exists. 

^"bo'rder ,0^" " * tranSit « ea a ^ the router is an area 
performed/" »" ' th * calculations must be 

- m First ; if N ' s ~— ~ tly 

e 7 ^"f^ P " hS the tra nsit area A _ 

fro'rthe'routing^abl^tw^h " th " removes Paths 
invalidated. The ent™^ ^ he 6ntry should be 
later comparisons. S the f h ° Uld be »«v«J for 

calculation in Section 16 3 
be run again for the sinolo ^ . ' 

this , ^^xnation N. If the results 

co T le C te C rou a tin3 ^.^I^o ^ b ° " t0 • 
wxth the Di jkstra a i gor - a ^ Ulat ^" ™ sc be _ rerun sterting 
Otherwise, if the cost/pa ™ ?Z tl\ ln Sec ^°n 16.1. 

would be the case for a TvrL 4 " AS bo ™tery router f as 

folding Presses ha^^^^' ~ tj an y 

« xx Ab external -LSAs will 
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have to be reexamined by renmni 

Section 16.4. otherwise if? f "lculation in 

single "^-"^ « Section ' 16^ ^usTbe^ Reachable, the 

ierun tor the 



must 
of 



destination n in ^ 
exists. a " alternate external route to N 



16.6. 



incremental updates ~ AS-externel -LSAs 
When a new AS-extprn^i r OA 

contained in^dy o^S ? f l£ the "^SST^ 

no r a e r c e a a i c ° u r i atlo rL er - area ™« * ^<2%Lll£ X ~* *" 
"ecessar, finternai roufces ^ 

£S o P n r r y C 1or tho n se Se A C S t10 ""- — be 

» Before this prccedS"^"™ 1 ""*. "ho,, destination ■ 

Performed, the present routing 



table entry for N should be invalidated. 



16.7. Events generated as a result of routing table changes 

Changes to routing table entries sometimes cause the OSPF area 

border routers to take additional actions. These routers need 
to act on the following routing table changes: 



changed. 



change 



The 



cost or 



path type of a routing table entry has 



If the destination described by this entry is a Network or 
AS boundary router, and this is not simply a 

of AS 

external routes , new suramary-LSAs may have to be generated 
(potentially one for each attached area,, including the 
backbone). See Section 12.4.3 for more information. If a 
previously advertised entry has been deleted, or is no 

longer advertisable to a particular area, the LSA must be 
flushed from the routing domain by setting its LS age to 
MaxAge and reflooding {see Section 14.1). 

A routing table entry associated with a configured virtual 
link has changed. The destination of such a routing table 
entry is an area border router. The change indicates a 

'modification to the virtual link's cost or viability. 
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If the entry indicates that 



the area border router is 



newly 

to 
the 
the 



reachable, the corresponding virtual link is now 
operational. An InterfaceUp event should be generated for 
the virtual link, which will cause a virtual adjacency 

begin to form (see Section 10.3). At this time 
virtual 

link's IP interface address and 
virtual neighbor's 

Neighbor IP address are also calculated. 

If the entry indicates that the area border router is no 

longer reachable, the virtual link and its associated 
adjacency should be destroyed. This means an Inter faceDown 
event should be generated for the associated virtual link. 



for 



If the cost 
established 



of the entry has changed, and there is a fully 
virtual adjacency, a new router-LSA 



the 



backbone must be originated, 
routing table changes. 



This in turn may cause further 



16.8. Equal-cost multipath 

The OSPF protocol maintains multiple equal-cost routes to all 
destinations. This can be seen in the steps used above to 

calculate the routing table, and in the definition of the 



routing table structure. 



Each one of the multiple routes will be of the same type 

{ intra-.area, inter-area, type 1 external or type 2 external), 

cost, and will have the same associated area. However, each 
route may specify a separate next hop and Advertising router. 

There is no requirement that a router running OSPF keep track 

of 

all possible equal-cost routes to a destination. An 
implementation may choose to keep only a fixed number of routes 
to any given destination. This does not affect any of the 

algorithms presented in this specification. 
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Footnotes 



[l]The graph's vertices represent either routers, transit networks, 
or stub networks. Since routers may belong to multiple areas, it is 
not possible to color the graph's vertices. 

(2) It is possible for ail of a router's interfaces to be unnumbered 
point-to-point links. In this case, an IP address must be assigned 
to the router. This address will then be advertised in 
the router's 

router-LSA as a host route. 

(3 ] Note that in these cases both interfaces, the non-virtual and 

the 

virtual, would have the same. IP address. 

(4)Note that no host route is generated for, and no IP packets 

can 

be addressed to, interfaces to unnumbered point-to-point 

networks . 

This is regardless of such an interface's state. 

(5]It is instructive to see what happens when the Designated 

Router 

for the network crashes. Call the Designated Router for the 

network 

RT1 , and the Backup Designated Router RT2 . If Router RT1 crashes 
(or maybe its interface to the network dies) , the other routers 

on 

the network will detect RTl ' s absence within 

RouterDeadlnterval 

seconds. All routers may not detect this at precisely the same 



d°es ti :fi 1 , the r ° Uters th ^ detect RT1 , S ah 

R , f ° r a time s , * enCe bef °re RT2 

Backup e ' select RT2 to be ho.-K „ 

Designated Router Wh designated R outer and 

Designated ° Uter P «°r lt y will the remaining ro 

Router. sel ected as Backup 

f6]On point-to • 

neighbor on virtual , • ^ewise. existence of 

s^Tus'eT" H °r VSr ' in b - n ^ t he S se n ^ s Cated * «- routing tabl 
- bi ^-ctionar hl a S nd en th r r that c °^ca ci ^ e h » eli ° ^"ocof i s 
"uting protocol 'l^f r that «<* of the " ei ^" 
I' J When the in f "^tioning 
may be Che ^entity of the M ^ 

a Q-lt. co^on for a neighbor ■ ^ *•= 

St3t — router 
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^-S-LSt^ilr^".- th " "-eans that th 

»I*>t. that it • " ROUter>S Le " C ^ re S ° me 
of its at lC 15 Possible for 

-^S^r^^.^-cencies by sett^T ^ «» 
Exstart state. th «"fore to also 

o f oip 9 ; The -ace of XP networks and th 

addre R s°s Uter ^ ~erlap. That is & . space 

w «ich is identical , whP ne tvork may have 

-uter-s Router r ^ considered as a 3 

' 10 J Discard" entri»« 

0n ~ more specific 

contiguous subnet m*<=L- P^cxfic than the 

°SPF. protocol. ^"tions cannot be handled 



. ^-iirSe^^^e^-"^ const r- ic indic — 

single ges ' ln seconds, that can occur for a 

two LSA inSC -« - it is flooded throughout the routing domain „ 

different^"' 6 " by m0re Chan «=hi.. they are assumed Co be 

instances of the same LSA Tf , ie „ 

restarts Thls c »n occur when a router 

Section 13 S 4 S for a more f detailf A ' S Previous Ls sequence number. See 
cq U3 )W hen two LSAs have different Ls ^ ^ 

oe separate instances.' This can occur when a router restarts 

thTtwo tLl — ^ e - ~ n^ er _ n ^ 

wrong LSA is accepted as newer thf ■ - 

originate another instance ' eL Q or ^ ina ting router will simply 
details. ce * Se * Section 13.4 for further 

.^^^^^.•^^ -t be done based on 
when a network-^ must be ^^t^Z^^^^ 
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(15}This is the way RFC 1Sfn 

representation. It has i-hrlo ~T specified point-to-point 

the routing S n t-hni- 

to-point ChaC P^ets destined for the point- 

interface will actually be receive 

useful for diagnostic purposesfand .w, f , interfa " (which is 
bootstrapping of a neighbor with™,- C) lC . allo «s network 
bootstrap gnoor. Without requiring that . the 

program contain an OSPF implementation. 
^US.This is the more traditiQnai point . to . point representation 
by protocols such as Rip. 



are 



[17}This clause covers the cas P . T„t- 

summarized to the backbone Thi^ 7 ^ r ° UteS are not 

This is because inter-area routes 
always associated with the backbone area. 

(18)This clause is only invnir^ u 

only invoked when a non-backbone Area A 



next 



supports 

For CranSit data Craffic 'ie-. has TransitCapability set to TRUE). 

^^'/"."^ area configuration of Figure 6. Area 2 can support 
RT10 and rt - CO C ° nfi S"^ virtual link between Routers 

RT10 and RT11. As a result. Router RT11 need only 

originate a single 

sumrnary-LSA into Area 2 (having the collapsed destination N9- 
.N11,H1), sxnce all of Router RTll's other eligible routes have 

bv^th^ 0 ^^' 0 /^ 2 ltSelf Und aS SUCh onl * need be advertised 
RT7 ) border routers; m this case. Routers RT10 and 

(19] By keeping more information in the routing table it 
is possible • 

for an implementation to recalculate the shortest path 

tree tor only 

a single area In fact, there are incremental algorithms that allow 
an implementation to recalculate only a portion of a single area's 
the Sh ° rteSt P* th tree [Refl, . However, these algorithm! are be^nd 

scope of this specification. 

C20)This is how the Link state request list is emptied which 

eventually causes the neighbor state to transition toTSll See 
Section 10.9 for more details. iee 

(21]It should be a relatively rare occurrence for an LSA-s LS aoe to 
reach MaxAge in this fashion. Usually, the LSA will be replacefby 

-° Y Standards Track [Page 181 , 
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a more recent instance before it ages out. 

(22) Strictly speaking, because of equal-cost multipath, the 
algorithm does not create a tree. We continue to use the 'tree' 

existing 109 * ^ " " h " C ° C ^ S m °" "t« in tta 

literature . 

(23) Note that the presence of any link back to V is sufficient; 
need not be the matching half of the link under consideration from 
to W. This is enough to ensure that, before data traffic flows 

55*2 s y n P c a hroni f Z ed ighb ° rlng 4* *™ 

(24) When the forwarding address is non-zero, it should point to a 
router belonging to another Autonomous System 

See Section 12.4.4 
for- more details. 
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A. OSPF data formats 

This appendix describes the format of OSPF 
protocol packets and OSPF 

LSAs. The OSPF protocol runs directly over the IP network layer 

Before any data formats are described, the details of the OSPF 
encapsulation are explained. 

Next the OSPF Options field is described. This field describes 

the" 10 " O^PF r ^^^^ Z* ^ bS -PP-ted by^'eTcf 

OSPF routing domain. The OSPF Options field is contained in 

Hello packets. Database Description packets and in OSPF LSAs . 

OSPF packet formats are detailed in Section A 3 

A description of 

OSPF LSAs appears in Section A. 4. 

A.l Encapsulation of OSPF packets 

QspF 0SPF runs directly over the Internet Protocols network layer. 

link PaCketS therefore encapsulated solely by IP and local data- 

headers . 

OSPF does not define a way to fragment its protocol packets and 

than P ° n " fragmentati °" "hen transmitting packet! larger 

packets can ITT " " eC — • Wh of OSPF 

to 65,535 bytes (including the IP header). The OSPF packet types 
that are likely to be large (Database Description Packets Link 

State Request. Link State Update, and Link State Acknowledgment 
packets) can usually be split into several separate protocol 
^ " lth ° u * loss of functionality. This is recommended; IP 

fragmentation should be avoided whenever possible. Using this 

reasoning, an attempt should be made to limit the sizes of OSPF 
packets sent over virtual links to 576 bytes unless Path MTU 

Discovery is being performed (see (Ref22](. 



The 



hop 



other important features of OSPF's IP encapsulation are: 

«^°L IP " ul ^ casC - Some 0SPF messages are multicast, when 

sent over broadcast networks. Two distinct IP multicast 
chf,!?H w , Packets sent to these multicast addresses 

should never be forwarded; they are meant to travel a single 

only. To ensure that these packets will not travel multiple 
hops, their IP TTL must be set to I multiple 
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AllSPFRouters 

Toi S n m n 1 = iCaSC address has been assigned the value 
Co 224.0.0.5. All routers running OSPF should be prepared 

receive packets sent to this address. Hello packets are 

oro a oLr nC V , C ° thlS destination. Also , certain OSPF 

protocol packets are sent to this address during the 
flooding procedure. 

AllDRouters 

^i S n m n 1 ^ iCaSt address »»* b *en assigned the value 
Router m Lr H °% si ^^ R °"ter and Backup Designated 

this Prepared to receive packets destined co 

address Certain OSPF protocol packets are sent to this 
address during the flooding procedure. 

registered " " Pr ° C ° Co1 nuniber ■ This number has been 

with the Network Information Center. IP protocol number 
assignments are documented in (Refll). er 

o All OSPF routing protocol packets are sent using the normal 
service TOS value of binary 0000 defined in [Refl2° 

o Routing protocol packets are sent with IP precedence set to 

Internetwork Control . OSPF protocol packets should be given 
precedence over regular ip d*i-* t „„ • . L s , 

and ta traffic, m both sending 

receiving. Setting the IP precedence field in the IP header to 
internetwork Control (RefSJ may help implement this objective. 
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A. 2 The Options field 

Database ^ ° Pei ° nS HM " *» OSPF Hello packets. 

enab^ros^ 10 " *" d a11 ^As . The Options field 

h —"caL^^eL'^bhrtf L^el JTl^ - - 

Through Cy J - ev el to other OSPF routers. 

this mechanism routers of diff^^i™ ^ • «, • . 

within axttenng capabilities can be mixed 

an OSPF routing domain. 

When used in Hello packets h K Q . 

i reject a neighbor because if a caoabiTi IT* ■ * leld K all °^ - router to 

Alternatively capability mismatch. 

of its reduced f unctionali tv T**t-i^ a - ■ 
LSAs 1Cy " Lastly, listing capabilities i n 

allows routers to forward t- ra ffi« 

routers, by excluding h arOUnd educed functionality 

calculation. eXClU<3in 9 them '"m Parts of the routing table 

Five bits of the OSPF Options field h=.„~ k 

only one (the E-bit) is described ^w , !" assi ^^. although 
is described briefly below Rout^ Y ^ thi » mem °- "t 

clear) ' Routers should reset (i. e 

pack e ts re or 9niZed bitS in thS ° PCi0ns ^n sending Hello 

rou^s^ounterlng ^^^^T^ ^ 
Packets, Database Description packers £ LSAs sh Th*^ Hel10 
capability and process the packet/LSA nor^lly 13n ° re Che 

-i _ 

1-liLl I °C | EA | N/P |"mc"|"b"""|"* I 

+ 

The Options field 

E-bit 

h . d^crrbed^rSec^ons^T ^"^JrVS - 
this memo. X 10 - 8 an <3 12.1.2 of 

MC-bit 

This bit describes whether IP multicast 

according to the specifications in fReflSJ^ 3 forw ^ded 
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N/P-bit 

This bit describes the handling of n 

in xing of Type-7 LSAs, as specified 

[Refl9] . 

EA-bit 

This bit describes the routers ^ n • 

forward External -At trTwJ re* Wlllln ^ ess to receive and 
external At trxbutes-LSAs . as specified in [Ref20J . 

DC-bit 

This bit describes the router's H^/n • - „ 

as cer s handling of demand circuits. 

specified in [Ref21J. 
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A. 3 OSPF Packet Formats 

packet^ ar ^ s Ve dlStinCt ° SPF ■«*« ^es. 

^st. Wi L h c K St^ L ytS h X er d ™ S h — * -«ib- 
ion. ype then described in a succeeding 

All OSPF packet type? (Qther fchan ^ ospp HeiiQ pacfcetsj ^ 

floodinl oi AS LS L 0 \„r X o^„o e ut Li ^ he St o^% UPd % te ^-nt the 

Qf P-tocoi packets LtTL^ed ^a^V' 

-s is also understood. The format „ f ^ ±- ^ ^ 

Section 8.2. reCeiVe Massing of OSPF packets is detailed in 

lection^^a.l. ° f ° SPF P^kets is explained 



section. 



All 

with 



The 

in 
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A. 3.1 The OSPF packet header 

H^ 0 c^a P ^%\r t ch r r in 1 o C r h m : t Sta " d « d 24 This 

packet -ho« 1^ ««^°? or C ° ^—" whether 

i-urcner processing. This 



0 x 

0123 4 5 6 7 8 9 0 2 3 

~ i' 0 . 1 1 2 3 4 5 012 



4 *?+f + \ ' » • ' 8 9 0 1 2 3 4 5 



~ + - + -- + - + - + _ + + *°"ter ID r " + —+--J.- + - + - + , + -+- + - + - + 

+ + - + + - + _ + . + _ + | 

Checksum * + + + - + 



" " -p— -+- + - + 

Authentication 

Authentication ' ' "~~" r "~-''-" + - + -+-+-+-+-. + 



Authentication + ~ + ~"*- + - + -+-^-+-+-+- + - + 



■*■*-*-*- J. 



Version # 
Th 
of 

Type 



The OSPF. version number This 

of the protocol. " Th ^ Wcif ication documents version 2 

pe 

The OSPF packet tVripc 

-3.S for ae^Us/— - - See Sec tions A . 3 . 2 throu< 
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Ty ^ e Description 



1 Hello " ■ " 

3 f at ^se Description 

t r Lln , k S tate Update 

3 Link - , 



State Acknowledgment 



Packet length 

ThG length °f the OSPF protocol 

1 PaCk - in Th,s length 



includes the standard OSPF header. 
Router ID 

The Router ID of the packet's source. 
Area ID 



travel a single hop only Packets f , S1 " 9le area - Most 

Unk are labelled wi.h th^ac^A^"^^ t 



.0.0.0. 
Checksum 

The standard IP check^m 
packet. cnecksum of the entire contents 



of the 



authentication t fieia PF ^ ^ ««t 

one's complement of the one's comolem^% Calc " lated the 16-bit 
words in the packet ex«onL ^ ^ SUm of a11 tfa e 16-bit 
packet's length i s not » f«thentication field. rf the 

packet is padded with Tbyte of ^ ™f *%° f ""^ W ° rds ' «^ 
checksum is considered to be cart n f tl before checksumming. The 
procedure; for some authentication t authe ntication 
calculation is omitted typeS the che <=ksum 

AuType 

current^"" 10 "- — ££SSTk». l^the" ^ ^ 

defined authentication types. 
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Authentication 

Appendix D^for details ^ authentica tion scheme. See 
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A. 3. 2 The Hello packet 

Hello packets are OSPF packet i mu 

tQ Periodical^ on alI i n t L^%^ t ^ 1 1 u di h --rL a a1 e 1 t Lksr ST order 

establish and maintain neighbor rel^inncKi^ 

Packets are multicast on thoL k f P ' In addi tion. Hello 

multicast C ° n th ° Se P h y«cal networks having a 

neighboring^' C&Pabilit ^ tabling dynamic discovery of 
routers . 

certain r ° UCerS c °™ected to a cordon network must agree on 

^^Sr^T&uffi 1 ?^* "? interval, . 

inhibit t „ 0 f ° P? C ' s ° that differences 

detailed forming of neighbor relationships. A 

pressed"" 10 " ° f ' ^ Pressing for Hello packets is 

-section 10.5. The sending of Hello packets is covered in Section 

3 I 5 6 7 1 1 I I 8 9 ° ' 2 3 4 5 3 6 7 8 9 ' " o 1 2 



Version SI L ' I " + "r + C + " + "" + " + "" f ~ + " + "" f -^~ + " + - + - + 

I 1 I Packet length 

r* - --- r - -. 

r--'- ;;:;•-*;;-*-* *- J :-- 
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I Neighbor + - + - + _ + _ 

+ -+- + - + - + - + - + - + - + - + - + - + - + - + - + ^ 

Network mask 

smiles tiTo^:^ zsjrv-*- — **< 

used for suonettin*. t^ S^ll Oxffr^ ^ 

Options 

The optional capabilities supported bv the ™„t-^ 

in Section A. 2. yp Dy the router - as documented 

HelloXnterval 

The number of seconds between this router's Hello packets. 
Rtr Pri 

This router's Router priori t->, „ ' , . 

Designated Priority. used m (Backup) 

RouterDeadlnterval 

The number of seconds before declaring a silent router down. 
Designated Router ' - 

O.O.O.0 ere ^ I? int « f *« address on the network. Set to 

if there is no Designated Router. 
Backup Designated Router 



cnere is no Backup Designated Router. 

Neighbor 

The Router IDs of each router- u 

been seen recently on the network Hec e n e r Ud HeUO PacketS have 
RouterDeadlnterval seconds Recently means in the last 
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A. 3. 3 The Database Description packet 

These a p:ckecs DeSCriPti ° n PaCketS 0SPP Packet type 2. 

They ar aescr ib e Chan9ed ^ ™ ad ^«ncy is being initialized. 

^ t he contents of che link . state datafaase Muitipie pacfcets ^ 

used to describe the database For 

procedure is used. One of the ro „L thls / ur Pose a poll-response 
Descr^on ^ ^ ^ ^^^^..^ 

Krs :s x g b ^ ase Des — 

polls via the Packets ■ ^D^ence^^ 363 Unked t0 

3 4 5 6 7 till 8 9 ° ' 2 3 4 5 3 « 7 8 9 0 1 2 

r^trr-p'*"*"; — rr + r + — 

J ' z I Packet length 

r "*""^;;rs r - 

; -;;:r--;; 

i::::^::::.;:::-^ H 



A^ntlc^on^ + -« 



+-+-+-+- 



+ Au C he„ti^;!; n + " +_+ ^" + - + - + - + - + - + - + -|- + - + — 

Interface MTU + + ~ + ~ + ~ + - + - + - + - + - + -+- + - + -+-+- + --+- + - + - + 



. + - + - ——♦— + _ + _ + _;_ + + °ff 0nS |0|0|0|0|0|I|M|MS 
! ^ DD sequence number 



+ - I 
I 

p An LSA Header ' + 

i 



+ - 

I 
I 



- + - + -+- + - + - + - + -+--f 



-+ 

I 
I 
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The format of the Database Description packet is very similar to 

both the Link State Request and Link State Acknowledgment 

packets . 

The main part of all three is a list of items, each item 

describing 

a piece of the link-state database. The sending of Database 
Description Packets is documented in Section 10.8. The 

reception of 

Database Description packets is documented in Section 10.6. 
Interface MTU 

The size in bytes of the largest IP datagram that can be sent 
out the associated interface, without fragmentation. The MTUs 

of common Internet link types can be found in Table 7-1 of 
(Ref22) . Interface MTU should be set to 0 in Database 
Description packets sent over virtual links. 

Options 

The optional capabilities supported by the router, as documented 
in Section A. 2. 

I-bit 

The Init bit. When set to 1, this packet is the first in the 
sequence of Database Description Packets. 

M-bit 

The More bit. When set to 1 , it indicates that more Database 
Description Packets are to follow. 

MS-bit 

The Master /Slave bit. When set to 1, it indicates .that the 

router is the master during the Database Exchange process. 

Otherwise, the router is the slave. 

DD sequence number 

Used to sequence the collection of Database 

Description Packets . 

The initial value (indicated by the Init bit being set) should 

be unique. The DD sequence number then increments until the 
complete database description has been sent. 

The rest of the packet consists of a {possibly partial) list 

of the 

link-state database'.s pieces. Each LSA in the database is 
described 

by its LSA header. The LSA header is documented 

in Section A . 4 . 1 . 

It contains all the information required to uniquely identify 

both 



the LSA and the LSA's current instance. 
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A. 3. 4 The Link State Request packet 

exchangLr^ 6 PaCketS ° SPF P acket ^ 3 . After 

may ° aCabaSe Des <^iPti°n packets with a neighboring router, a router 

find that parts of its link-state database are out-of-date. The 
Link State Request packet is used to request the pieces of the 

Ro™^^ 5 ? a ^ abase that are m °re up-to-date. Multiple Link State 
Request packets may need to be used. 

A router that sends a Link State Request' packet has in 
mind the 

precise instance of the database pieces it is requesting Each 
check^m^^and J*'""* * ^ - 

age, although these fields are not specified in the Link State 

The — - — — — n e t 

in Section Se " din9 ° E Li " k StatS Re<IUest packets is documented 

Section^O. 7 eCePti ° n ° f StM ' Req " eSt packets is documented in 

3 I III till 39 ° 1 ' 2345 3 ^.3 ^ '.12 



» 
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A. 3. 5 The Link State Update packet 

Link State Update packets are OSPF oackei- t-,™ 
implement the flooding of LSAs . Each k sTate'uod^ 6 
carries a collects of LSAs one hop furtnerlroV.heir o^n. 



Several LSAs may be included in a single packet. 

L r S^nc^c e k ecs 00 ^ r L T «-.«c^^S- in^nfstale' 

necessary^the remitted LSAs^T^ys^sent drrect? ^f^ S ^ 
consu^ec^* °" ^ S^-SSEV' LsL. 

3 4° 5 6 7 8 9 0 ' 2 3 4 5 3 6 7 8 9 0 1 2 

I I 4 | Packet length 

.- + - + _ + ^_ + .^ + _ + _ + __ + _.^_ + _ + __ + __ + ^_ + ^_ + 

I Router ID i + + + 

_____ + + _ + 

r~-ss^* ■ — r + — -zsr — p- J - + — - + 

1 :.;;:;:i:_:i: n * 

I" zzzizziz * 

+ -vzs A r— r —L-^ 

P + - + . + .__ + _ t _ + - + - + - + - + - + - + - + - + . + .__ + . + . + _ + _i_ + _ + _ + . + _ + . + _ + _ + 

l 

I LSAs i 

+ - I 
I + - + 
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» LSAs 

The number of LSAs included in this update. 

list Th of LSAs^ ° f Llnk StaC£ U * date e-ket consists of a 

A a 4 h l LS p e ^ied formats^Tthe'd ff 6 T^' in SeCti °" 

in Section A. 4. ^ dlfferent types of LSAs are described 



Moy 

Standards Track 

[Page 200) 

RFC 2328 OSPP Version2 . 

April 1998 



A. 3. S The Link State Acknowledgment packet 
Link State Acknowledgment Park,,* 

the flooding of S r , S ° SPF PaCket ^ 5. To make 

acknowledged. ? his a^£^' f^f «»• are explicit 1^ 
sendmg and receiving of Link ^ I accomplished through the 
Multiple LSAs can be acknowledged ^ A ^°«ledgment packets. 
Acknowledgment packet. owlea 9 ed "» a single Link state 

o[ « „ «... o£ eh . „„ aing lncertra ^ ^ 

State Acknowledgement packets is 
documented in Section 13.5 L 0 

Acknowledgement packets is documented ^Section ^ 
Description ° E ChlS PackeC » similar to that of the Data 



0 

0 12 3 



'.iii-JJ} 1 ' 8581 ji,s ! «'»» ... 



+ - + - + - + - + _ + _ + _ + _ + + ID . — — — — - 

I Checksum +_ r + " + " + " + ~''""" + - + - + - , - + - + - + - + - + -! ♦ . 

+-+-+-+-*-.^_ . . I AuType | 
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I An LSA Header ' 



I 
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I 



Each acknowledged L9A ; c ^ 

current instance. SA a " d the 
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A - 4 LSA formats 

This memo defines five distin,, . 

a standard 20 byte LSA ht * types of L SAs . Each rc a k 

m Section ^ heade * • This header is e^ainS ^ With 

A- 4.1. Succeeding sections hh 

then diagram the separate r qa - 
Each LSA describes a piece of th n YPeS * 
orxgxnates a router-L j f a ^° SPF ^"ting domain Everv r „ 

elected Designated Router ?^ addltl °n, whenever the ^7 router 

of LSAs may aiso originates a network-LSA * 15 

(see Section 12 41 originated k LSA ' 0t her types 

then flooded throughout thf 1 ^ 

link-state database. 
Prom the link st t- 



-° Y Standards Track t Page 203, 

RFC232S OSPF version 2 April 1998 

A. 4.1 The LSA header 

contains With 9 COran, ° n 20 ^ader. This header 

State™" 911 inf0rmaCio " to «ni V .ly identify the LSA ,LS Cype . LinJc 

LSA^may and Adve "ising Router,. Multiple instances of che 

necessary ^ r ° Uting d ° main at Che — • time. It is then 

to determine which instanrp ^ 
accomplished by " 13 more recent. This is 

« t ^« ^ n ^ and LS checksum fields 
3 ill' till a9 ° l ^4S 3 6 7 8 9 0 1 2 

n:::::HE:^ 

I Link Stace'lV + - + " + - + - + - + - + 

Advertising Router 



LS sequence number ++++++ 

i 



+ _ + __ 



LS age 

The time in seconds since the LSA was originated. 
Options 

the 6 ^JS 1 diS 111 Sw.. ,u SKrS2 1 ,w th t f escr ibed porti - ° E 

in Section A . 2 . optional capabilities are documented 



LS type 



(see 



Section 12.1.3 for further explanation): 
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Type Description 

Router-LSAs 
Network- LSAs 

Summary-LSAs (IP network) 
Summary-LSAs ( ASBR) 
AS-external-LSAs 



Link State ID 

field 3 aescrlbe d by the LSA. The contents of this 

depend on the LSA"s LS tvr>e P^,- , 

Link State ID is set to SI'tp , example. ln network-LSAs the 
network-. Designated Router (from t?*** ° f the 

can be derived) . The Link Statin - \ ^ network 's IP address 
Section 12.1.4 * ID " further discussed in 

Advertising Router 

The Router ID of the rmifor i-v..- ■ • 

example, in network^LSAs thil e °"? lnated th * ^SA. For 
the network's Designated Router" " ^ t0 the R ° Uter 10 °* 
LS sequence number 

LS checksum 

Inclu^nf tnel^eader but ex^ng^ 5 

Section 12.1.7 for more detail" * 9e Cleld - See 

length 

hea^er" 9 ^ byC6S ° f Che . LSA ' ™is includes the 20 bvte LSA 
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A. 4.2 Router-LSAs 



Router-LSAs are the Type 1 LSAs. Each router in an area 
originates 

a router-LSA. The LSA describes the state and cost of the 
router * s 

links (i.e., interfaces) to the area. All of the router's links 

to 

the area must be described in a single router-LSA- For details 

concerning the construction of router-LSAs, see Section 
12.4.1. 



0 12 3 

0123 4567 8901 2345 6789 

4567 8901 
+ _ + _ + ^ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ 

| LS age | Options | 1 

+ + - + - + - + - + - + - + - + - + + - +- + - + _ + _ + _ +_+_ + _ + _ + _ + _ 

| Link State ID 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Advertising Router | 

H * ► • 1 * » 1 1 1 1 1 * > » 1 • f - + + - *-->— + - + + 

| LS sequence number 



0 12 



- + - + - + - + --» 



-+-+-+-+-+-+- 



-+-+-+-+-+- 



LS checksum | 


length ; 


0 |V|E|B| 0 | 


# links | 


Link ID 


1 


Link Data 


1 


Type | # TOS | 


metric | 



(._ + _ + _ + - 

TOS 



I o 

+ - + - + - + 
Link ID 
- + --»-- + - + - + - + - + - 
Link Data 



+- + - + - + -+-- + - + - + -4 



- + - + - + -H — H +-+-H — 4- — 4 I h 

TOS metric | 

--» I t I — 4 ^ — f — « I I » * — + - + -+- 

I 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

I 
I 
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In router-LSAs, the Link State ID field is set to the router's OSPF 
Router ID. Router-LSAs are flooded throughout a single area only. 

bit V 

When set, the router is an endpoint of one or more fully 
.adjacent virtual links having the described area as Transit area 



(V is for virtual link endpoint) . 
bit E 

When set, the router is *n aq k« ^ 

external) . AS bou ndary router (E is for 

bit B 

for ^ e T: iS - — border router (B is 

t links 

^ The „ UInber of router Unks described ^ chisLsA ^ s ^ t 

ttatofl coUec tlo „ o£ router links ( . e infcerfaces) ^ ^ 

( . Jhe following fields are used to describe ^ ^ 

d ^e erfaC ^ e f ££ S£t es n ^ h r k ^ e of ^ oelow ^p e field, . 

described. it may Cne klnd of lmk being 

be a link to a transit network m 

network. The values of 111 ' ^° an ^her router or to a stub 

link depend on the link's Type For d *?~ ih ^ * router 

assocxated 32-bit Link Data field eX ^ e ' ea <* link has an 

networks this " "eld. For links to stub 

field specifies the network's TP .a, 

types CW ° r * s IP ^dress mask. For other link 

address\ ^ **** field -P-cifi.. the router interface's IP 

Type 

followin^ 1 ^ d ""ipti on of the rQuter Unk ^ q£ ^ 

Note that host routes are class if 

with network mask of Oxffffffff aS Ilnks to stu *> networks 
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Type Description 



1 



3> ^l"^ 1 ^^^™^ 
4 Sl""^', > 



Link ID 

vaiue Identifies the object chac chis router cQnnects CQ 

depend on the Uak .. ^ ^ ^ ^ ^ 

also originates an LSA (i e 

network) the Link ID is equal ' to tZZ ■ u'" ° r a Crans it 

. State ID. This provideT neighboring LSA's Link 

neighboring * es the ke Y for looking up the 

-IcuLtio^st Sectio^^^^^^. table 
Type Link ID 



2 Neighb^rTnTrouter-s Router ID 

3 IP nff S 2 ° f Des i3nated Router 
Neighboring router's Router ID 

Link Data 

r t ub e n:?:ir n k S dep L e L d k s e P ^: s ^: - «~ tl « to 

mask. For unnumbered point- to-oo?^ ""work's IP address 
the interface's MIB-n ^^1?^?™*°^°™- U 

^ .uild process, when .ESS* -j-g-J «^ 

See Section 16.1.1 for .ore details. 
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The number of different TO<; ■ 

counting the required link metric^ 5°* this U - nk ' not 
metrxc in (RefSJJ. For • examni I • i f Srred to as th * TOS 0 
are given, this field ,s set co o° additio ^ ™* -etrics 



etric 

The cost of using this router link. 



Additional TOS-specific i n f„ rm „ • 

backward compatibility with ■ 3lS ° be deluded, for 

^ specification (( Re f91) . within £^1^^'^™^ 

- T OS-s P ecific link information ma y be encoded as follows. 



enco^ag of " ^ ° f that this refe ~ to. The 

TOS in OSPF LSAs is described in Section 12.3. 



TOS . metric 

TOS-specific metric information. 
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A. 4.3 Network-LSAs 

Network-LSAs are the Tvne ? rca~ 
for We 2 LSAs - network-LSA is originated 

each broadcast and NBMA network in th P **-o* u,k^k 

more routers. The network-LSA ^ • ? . SUpP ° rts two or 

Designated Router The LSA LZlSt™ ?i ^ ^ " et "°rk's 

the describes all routers attached to 

Router. interface address of the Designated 

This^ 6 distance fr °™ ^e network to ail attached routers is zero 

3 ill I till S9 ° l ^4 5 3 6 7 8 9 0 1 2 

1 LS a « e I Options | 2 I 



■h-+-+- + -t- + - + - + - + . + _ + _ + . < 



"+-+-+-+-+-+-+- 



- + - + - + _+_ + . + _ + _ + _ 4 



I Link State ID i 

+ - + - + - + - + - + - + - + -•»—■*-- + - + - + - + - + <- + _ + _.- 1 
I Advertising Router 



I 



LS checksum 



LS sequence number 



| length 



I Network Mask | 

I Attached Router j 



Network Mask 

The IP address mask for the network. For example, a class A 
network would have the mask Oxff 000000. 
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Attached Router 

The Router IDs of each of the routers attached to the network 
Actually only those routers that are fully adjacent to the 
Designated Router are listed. The Designated Router includes 

deduct 1 " Ch f S liS ^' The nUmber ° f routers included can be 
deduced from the LSA header's length field. 
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A. 4. 4 Summary-LSAs 

Summary-LSAs are the Type 3 and 4 LSAs . These LSAs are 

originated 

by area border routers. Summary-LSAs describe inter-area 
destinations. For details concerning the construction of summary- 
LSAs, see Section 12.4.3. Y 

Type 3 summary-LSAs are used when the destination is an IP network 
In this case the LSA's Link State ID field is an 

IP network number 

(if necessary, the Link State ID can also have one or more of 

the 

network's "host- bits set; see Appendix E for details). When the 
destination is an AS boundary router, a Type 4 summary-LSA is 
used, 

and the Link State ID field is the AS boundary router's OSPF 

Router 

ID (To see why it is necessary to advertise the location 

or each 

Lin/^' C ° nSUlt Section 16 - 4 -> Other than the difference in the 

State ID field, the format of Type 3 and 4 summary-LSAs is 
identical . 



:°5S7 till 8 9 0 ' 2345 3 6 7 8 9 0 1 2 

' LS a 9 e I Options | 3 or 4 I 

^_ + _ + _ + . + _ + _ + . + _ + _ + _ + _ + _ + _ + _^ + _ + _ + ^_^ + _ + _ + _ + _^_ + _ + _ + _|_ + _ + _ + _ + 

I Link State ID | 

-+-+-+-+-+-+ 



+ - + - +_ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ 



j Advertising Router j 

I LS sequence number ! 

| LS checksum | length I 

|-*- + - + - + - + - + - + - + - + - + - + - + - + - + . + . + . + . + . + . + . + . + . + . + . + . + .;. + . + _ + _ + _ + 

I Network Mask I 



metric | 



I TOS 



•—•--+-+-+-+-+ 

TOS metric 
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F °r stub areas ts~>~ 

describe a S ' Type 3 summary- L sAs can al 

fper-area) default route n . USed t0 

^^areas instead Qf J^^^^* are used in stub 

ID Ascribing a default routes, 
is always set to Def i ' SU ™*ry-LSA' s LinJc s 

i. -t to 0.5.0^0 — — — on C0.0.0.., and the Network ^ 
Network Mask 

For Type 3 summary-LSAs t-hi 

location 3 add ™s* ™^ For"* 1 ™!? , "* ^"nation 
_ U3°e C a ti0 ? h r s f rie^VnoT^ va^^oT^^ the 

Type 4 eid ls not meaningful and must b *° uld be 

summary-LSAs. S * zero for 

metric 



The cost of this, route p_ 

-terface costs in * he ^ — ^ - th. 

Additional TOS-soPrif^ - - 

backward compact ^ ^^ 0r,nati °« «Y also be included > 
specif lcaciorl ([Refgn p Previous versions nf ' for 

T 1 0 n s fO ™ ti °" -oded^ folIo ^ — toT TOs-specif ic 

encoding of " ^ of S "vice that this metric 

TOS in OSPF LSAs is described ■ ^ 
aescrxbed ln Section 12 3 

TOS „.„-_., 



T0S metric 

TOS-specific metric information. 
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A. 4. 5 AS-external-LSAs 

AS-external-LSAs are the Tvne <; r cic ™ u 

AS boundary routers anddLlif , These LSAs are originated by 
For details in 1 ^ destinations . external to the AS. 

COncernlng the construction of AS- external -LSAs; 

Section 12.4.3. 

destination™ 1 - 1 ^ * Particular external 

nler ,if ^eces^ry^tnf EiS^S S - " T"*- « IP ~r« 
the networks -L, b. tfs^'L™ p P en al x° ^detai^ 

De f aulc ernal - LSAS alS ° " Sed to Scribe a default route. 

When e des a c r ribin1 fZt ault^out the ^ ^ 

to De o ea o 1 o tD o stinat ion (oo -°-°> £ ^x^rsr 5 set - 
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0123 4567 8901 •> i „ c , 

45 67 8901 H 9 0 1 2345 6789 012 

I Si-,*;:::-;; J — -.-.—.-..,-!..., 



Link State ID 



+ - + - + --t-- + - + - + - + _ + _ + _ + _ + _ + _ + 

i Advertising Router' ' ~ + " -J- - — - 

^ sequence number 



- + - + --* 



LS checksum + ! *~ + ~ + ~*- + -+- + - + - + - + -+- + - + - + --!-- + - + 

. . ^ ^ I length I 



metric , 



- + - + - 

-■•—+- + 



I Forwarding address 

p +-+ " +_+ - +- + -+-+-+-*-+-+-+-+- + _+_ + _ + . + _ + _ + _ + |_ 

I External Route Tag T 

i:r-~ T" ~*;sr«;:r~ ~4'*~ 



- + --*•- + - + - + - + - + - + - + - + 



Forwarding address 



+ - + - + _ + _ + + _ 



+ 
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External Route Tag 



Network Mask 

The IP address mask for the advertised destination For 

JESS'S; ^. advertising a cl * ss A — * -k Sf oooooo 

bit E 

The type of external metric. If bit E is set hho • 

(i.e., the same units as interface cost), 
metric 

externl^ ° f ^«pr*t.tion depends on the 

type indication (bit E above) . 
Forwarding address 
CQ Data traffic for the advertised destination will be forwarded 

tra f Crc dreSS wll l If oe he iS S " ^ *-*'*■<>• 

(i.e., 6 ^rwarded lns tead Co the ISA's originator 

the responsible AS boundary router) . 
External Route Tag 

u A s e r Dy C ""he^^prot^coT^self^r^ * ™ iS ™ 

communicate itself. it may be used to. 

information between AS boundary rouhpr . l . K 

such infection is outside the s^of tS^i'Si^™* 

^^icS^s c wS or " t s: • may also be inciuded - f - 

specification ((ReWM For Parous versions of the OSPF 

information li^coded^s follows: TOS -P~«ic 

concern. £ ^ ° f thaC the ^^io g fields 

encoding of TOS in OSPF LSAs is described in 
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bit E 

For backward-compatibility with fRef9] . 
T °S metric 

TOS-specific meCric information 

Forwarding address 

Per backward-compatibility with fRef9) . 

External Route Tag 

For backward-compatibility with tRef9J . 



Moy 

Standards Track 
RFC 2328 fPa ^ e 

OSPF Version 2 

April 1998 

B. Architectural Constants 

as S^EtS^ ^T^^ ^xed arc h ite ctural values 

bSRefreshTime. The sarae , . ^ by ™™* 

C. ^otocol^^^ion is use. for the 

iney are defined 

ned ln Appendix 

The name of o ach a . . .. 

raUeCtoi — ^liows, togecher 



with its 

-lue and a short description of its function _ 



LSRefreshTime 

The maximum time between di«sKr„,.. ■ - 

LSA. If th e LS age field of one° r f 9 ^ atl0nS ° f Secular 
-As reaches the „.? u . bs^f res^Lef ^ 

the 0 ^ A 91nate h d ead:r e r ^^L^T ^ 
of LSRefreshTime i s the same - The value 

set to 30 minutes. 



MinLS Interval 

The minimum time between di«st-,^. • • 

-A. The value of ^t^T^n ^«i«a« 
MinLSAr rival 

between" receptio^of "ew LSA e i ntr'^ U,n ^ me . th ^ ™st elapse 

instances received at higher ff=™ nstances d »"ng flooding. LSA 
value of MinLSArrival is set f"* 1 " 6 "" 63 a " discarded. Th* 

co 1 second. 

MaxAge 

The" maximum age that- r 

LSA's LS age . attain. When 

field reaches MaxAge, it is r P fi^ • 

LSA from the routing domain (sfe Section t0 fI " sh the 

are not used in rh* iZ * ■ Sectlon 14 > - LSAs of age MaxAoe 

^alue of ln the routing table calculation. ThT 

MaxAge is set to 1 hour. 

CheckAge 

When the age of an r • 

multiple of CheckAge. the Csa^ lM * !f tate datab ^e hits a 
incorrect checksum at this Cirae s^ferro^ 

value of CheckAge is set to 5 minutes. 
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MaxAgeDiff 

The maximum time dispersion hh^ 

throughout the AS. Most"? tn is time 0 ,""' " " LSA is «-ded 
LSAs sitting on router 0 L,, 6 13 acc °""ted for by the 

during the flooding proces's ^ThTTxL ^ * °" ' 

15 minutes. ine valu © of MaxAgeDiff i s set to 

LSInfinity 

^ K^SSll^S su h ^r y \s d r tin H Cl ° n ^ an 

an alternative to premature ag^o c ^ ^^"nal-LSAs as 

"efxned to be the 24-br c ^na 9 r y S : a e lu S e eC 0 t -" 11 14 ' 11 ' " « 

y vaiue of all ones: Oxffffff. 



Default Destination 

The Destination ID that indicates the default route This 

route 

is used when no other matching routing table entry can be 

found. 

The default destination can only be advertised in AS-external- 
LSAs and m stub areas' type 3 summary-LSAs . Its value- is the 
£ P o a ^ d £ ess 0.0.0.0. Its associated Network Mask is also always 

InitialSequenceNumber 

The value used for LS Sequence Number when originating the first 
instance of any LSA. Its value is the signed 32-bit integer 
0x80000001. 9 

MaxSequenceNumber 

The maximum value that LS Sequence Number can attain. Its value 
is the signed 32-bit integer 0x7fffffff. 
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C. Configurable Constants 

The OSPF protocol has quite a few configurable 

parameters . These 

parameters are listed below. They are grouped into general 
etc [ Unctlonal categories (area parameters, interface parameters. 

Sample values are given for some of the parameters. 



Some parameter settings need to be consistent among groups of 

routers. For example, all routers in an area must agree on that 
^'% Paramet ^ S ' T and a11 outers attached to a network must agree 
on that network's IP network number and mask. 

Some parameters may be determined by router algorithms outside of 
this specification (e.g., the address of a host connected to the 
router via a SLIP line). From OSPF's point of view, these items are 
still configurable. 

CI Global parameters 

In general, a separate copy of the OSPF protocol is run for 



each 

area. Because of this, most configuration parameters are 
defined on a per-area basis. The few global configuration 

parameters are listed below. 



address 



Router ID 

This is a 32-bit number that uniquely identifies the router 
in the Autonomous System. One algorithm for Router ID 
assignment is to choose the largest or smallest IP 



assigned to the router. If a router's OSPF Router ID is 
changed, the router's OSPF software should be restarted 
before the new Router ID takes effect. Before restarting in 
order to change its Router ID, the router should flush its 
self -originated LSAs from the routing domain (see Section 
14.1), or they will persist for up to MaxAge minutes. . 

RFCl583Compatibility 

Controls the preference rules used in Section 16.4 when 
choosing among multiple AS-external-LSAs advertising the 
same destination. When set to "enabled", the preference 
rules remain those specified by RFC 1583 ([Ref9]). When set 
to "disabled", the preference rules are those stated in 
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Section 16.4.1, which prevent routing loops when AS- • 
external -LSAs for the same destination have been originated 
from different areas. Set to. "enabled" by default. 

In order to minimize the chance of routing loops, all OSPF 
routers in an OSPF routing domain should have 
RFC158 3Compatibility set identically. When there are routers 
present that have not been updated with the functionality 
specified in Section 16.4.1 of this memo, all routers 



should 



have RFC1583Compatibility set to "enabled". Otherwise, all 
routers should have RFC1583Compatibili ty set to "disabled", 
preventing all routing loops. 

C.2- Area parameters 

All routers belonging to an area must agree on that area's 
configuration. Disagreements between two routers will lead to 
an inability for adjacencies to form between them, with a 

resulting hindrance to the flow of routing protocol and data 

traffic. The following items must be configured for an area: 

Area ID 

This is a 32-bit number that identifies the area. The Area 
ID of 0.0.0.0 is reserved for the backbone. If the area 
represents a subnetted network, the IP network number of the 
subnet ted network may be used tor the Area ID. 



List of. address ranges 

tIP address, mask] 

-"»^. js ssrs: 
S 1 "-""- -'srss..-a3as ttair 

networks" area membership. ' attached 
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OoNo^r luting 0 AdV - tiSe « 

External 'to j^"^ ^ r b °^r ies . 
advertised (via^ slZk^Tfl^llT^ " 
range. The route is advertised f^ 88 
address range's Status to ' Advertis^ ^ ^ 

As an example, suppose an IP suhnoh^ , . 

own OSPF area The Hot u " etworIt is to be its 

address range, whose IP address is the" ST"""** « - single 

subnetted network, and whose ™ s £ i« ?h ° f the 

or C address mask A s7™f the nat "ral class A, B 

external to the'area 2 ^ "° Uld be advertised 

network. desc "*>"S the entire subnetted 

Ext ernalRou t ingCapabi 1 i ty 

"^^t^ the 
area is called a "stub" ^luded from the area, the 

external destinations will be based ar-M " r ° Uting to 
summary route. The backbone cannot h° V" 3 de£aUlt 
area. Also, virtual links L„TJ be configured as a stub 
areas. For more inSStl^^sSfiFJl. Stub 
StubDefaul tCost 

router itself Ts^TTr^lT^ " 3 Stub " «*» the 

Stub D efaultCost%„dic\ r ^ b thf" os r rof r th th r f th f ' " 

C3 ■ Router interface parameters 

Some of the configurable router interf*™ 

P uucer interface parameters. (such as 

interface address and subnet mask) actual l„ i i 

SK) actu ally i m pi y properties of 



that 



the attached networks, and therefore must be consistent across 
all the routers attached to that network. The parameters. 

roust be configured for a router interface are: 
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IP interface address 

The IP protocol address for this interface. This 

uniquely 

identifies the router over the entire internet. An IP 
address is not required on point-to-point networks. Such 



a 



point-to-point network is called -unnumbered-. 



IP interface mask 

Also referred to as the subnet /network mask, this indicates 
the portion of the IP interface address that 

identifies the 

attached network. Masking the IP interface address with 

the 

IP interface mask yields the IP network, number of the 
attached network. . On point-to-point networks and virtual 
links, the IP interface mask is not defined. On these 
networks, the link itself is not assigned an IP network 
number, and so the addresses of each side of the link are 
assigned independently, if they are assigned at all. 

Area ID 

The OSPF area to which the 

attached network belongs. 

Interface output cost 

The cost of sending a packet on the interface, 

expressed in 

the link state metric. This is advertised as the link 

cost 

for this interface in the router's router-LSA. The 

interface 

output cost must always be greater than 0. 
Rxmtlnterval 

The number of seconds between LSA retransmissions, for 

adjacencies belonging to this interface. Also used when 
retransmitting Database Description and Link State Request 
Packets.. This should be well over the expected round-trip 
delay between any two routers on the attached network. - The 
setting of this value should be conservative or needless 
retransmissions will result. Sample value for a local area 
. network: 5 seconds. 

InfTransDelay 

The estimated number ot seconds it takes to transmit a 

Link 



State Update Packet over this interface. LS As contained in 
amn,mh packet must have their age incremented by thi 

c ount^h ranSmiSS1 ° n - This va ^ should take into 

account the transmission and propagation delays of the 
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for a int "face. It raust be greater than 0. Sample value 

local area network: 1 second. 
Router Priority 

An 8-bit unsigned integer. when two routers attached to 

wl h°l h° „ a ? mPt C ° beC ° me ^«3"»ted Router, one 
there highest Router Priority takes precedence. If 

is still a tie. the router with the highest Router ID 

precedence. A router whose Router Priority is set to 0 

ineligible to become Designated Router on the attached 
network^ Router Priority is on l y configured- for interfaces 
to broadcast and NBMA networks. K 

Hellolnterval 

Packets ^ len9th ° f Cime ' in seconds - between the Hello 

that the router sends on the interface. This value is 
advertised in the router's Hello Packets. It must be the 
same for all routers attached to a common network The 

Til be :ec t efh InterTa1 ' faSter topological changes 

will be detected; however, more OSPF routing protocol 
3o traffic will ensue. Sample value for a X 25 PDN network : 

10 seconds 0 ^ 3 ' "* * l0Cal " ea ""work: 



to 



RouterDeadlnterval 

After ceasing to hear a router's Hello Packets the „„„ hor 
of seconds before its neighbors declare the router down ^ 
This is also advertised in the router's Hello Packets in 
their RouterDeadlnterval field. This should be some 
mustl^th' . HelloIn terval (say 4) . This value again 

network. ' a " aChed to * «on 

AuType 

a tt^hfd" ^ e authenti "tion procedure to be used on the 
attached network. This value must be the same for all 
routers attached to the network. See Appendix D for a 
discussion of the defined authentication types. 

Authentication key 

This configured data allows the authentication procedure 

verify OSPF protocol packets received over the interface. 



example, if the AuType indicates simple password. 
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Authentication key would be a clear 64-bit password 

Authentication keys associated with the other OSPF 
authentication types are discussed in Appendix D. 

C.4 Virtual link parameters 

Virtual links are used to restore/increase connectivity of the 

backbone^ Virtual links may be configured between any pair of 

till r ™ te 5^ ha ™ interfaces to a common (non-backbone) 

point virtual link appears as an unnumbered point-to- 

link in the graph for the backbone. The virtual link must be 

configured in both of the area border routers. 

A virtual link appears in router-LSAs (for the backbone) as if 
\l hH^l! f ^ ar * te router interface to the backbone. As such, 
it has all of the parameters associated with a router interface 
(see Section C.3) . Although a virtual link acts like an interface 
unnumbered point-to-point link, it does have 

an associated IP 

interface address. This address is used as the IP source in 
OSPF protocol packets it sends along the virtual link, and is 
set dynamically during the routing table build process 
Interface output cost is also set dynamically on virtual ' links 
to be the cost of the mtra-area path between the two routers 
The parameter Rxmt Interval must be configured, and should 'be 

well over the. expected round-trip delay between the 

two routers . 

Irr S nnTh be ^ t0 ^i^* for « virtual link; it is better to 
not making it too large. Router Priority is 

used on virtual links. 

A virtual link is defined by the following two configurable 
parameters: the Router ID of the virtual link's other 
endpoint , 

and the (non-backbone) area through which the virtual link 



runs 



(referred to as the virtual link's Transit area). Virtual links 
cannot be configured through stub areas. virtual links 

C.5 NBMA network parameters _ 

OSPF treats an NBMA network much like it treats a broadcast 
network. Since there may be many routers attached to the 
This netW ° rk ' a Desi 9 nated Router is selected for the network. 

Designated Router then originates a network-LSA, which lists all 
routers attached to the NBMA network. 
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However, due Co the lack of broadcast capabilities, it may be 
necessary to use configuration parameters in the Designated 
Router selection. These parameters will only need to be 
configured in those routers that are themselves eligible to 
become Designated Router (i.e., those router's whose Router 

Priority for the network is non-zero) , and then only if no 
automatic procedure for discovering neighbors exists : 



network 



router 



List of all other attached routers 

The list of all other routers attached to the NBMA 



Each router is listed by its IP interface address on the 
network. Also, for each router listed, that router's 
eligibility to become Designated Router must be defined. 
When an interface to a NBMA network comes up, the 



sends Hello Packets only to those 

neighbors eligible to 

become Designated Router, until the identity of the 
Designated Router is discovered. 

Poll Interval 

If a neighboring router has become inactive (Hello 

Packets 

have not been seen for RouterDeadlnterval seconds) , it may 

still be necessary to send Hello Packets to the dead 
neighbor- These Hello Packets will be sent at the 

reduced 

rate Polllnterval , which should be much larger than 
Hellolnterval . Sample value for a PDN X-25 network: 2 
minutes . 

C.6 Point- to-MultiPoint network parameters 

On Point-to-MultiPoint networks, it may be necessary to 
configure the set of neighbors that are directly reachable over 
the Point- to-MultiPoint network. Each neighbor is identified by 
its IP address on the Point-to-Mul tiPoint network. Designated 
Routers are not elected on Point- to-Mul tiPoint 

networks, so the 

Designated Router eligibility of configured neighbors is 
undefined. 

Alternatively, neighbors on Point- to-MultiPoint networks may be 
dynamically discovered by lower-level protocols such 
'as Inverse 

ARP ( (Refl4) ) . 
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C.7 Host route parameters 



the 



Host routes are advertised in router-LSAs as stub networks with 
mask: Oxffffffff. They indicate either router interfaces to 

point-to-point networks, looped router interfaces, or IP hosts 

that are directly connected to the router (e.g., via a SLIP 
line) . For each host directly connected to 

router, the 

following items must be configured: 



Host IP 
The 



address 

IP address of the host. 



a packet to the host, in 



Cost of link to host 

The cost of sending 

terms of the 

link state metric. However, since the host probably has 
only a single connection to the internet, the actual 

configured cost in many cases is unimportant {i.e., will 
have no effect on routing) . 



Area ID 
The 



OSPF area to which the host belongs. 
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D. Authentication 

All OSPF protocol exchanges are authenticated. The OSPF packet 

header (see Section A. 3.1) includes an authentication type 

field, 

and 64-bits of data for use by the appropriate 

authentication scheme 



(determined by the type field) 



basis . 

Authentication types 0, l and 2 are defined 



this specification ' ' » re deElned »* 

the A11 ° ther a " "entication types are reserved for definition f 

I ANA (ianaeiSI.EDU). The cnrrpnf 1 ; c 

described below in Table 20 ° £ authentl ^tion types is 



AuType Description 



0 Null authentication 

1 Simple password 



2 

All others 



Cryptographic authentication 

Reserved for assignment by the 
I ANA (iana@ISI.EDU) 



Table 20: OSPF authentication types. 



D.l Null authentication 



Use of this authentication tvoe me»r,e hi, - 

over the network/subnet are not f f t * rouCln 9 exchanges 

authentication field in the SsPF head^ thentlcated " The 64-bit 
is not examined on packet reception Wh^ "i^*™ a ^ hi ^-. it 
authentication, the entire conf! ? T frying Null 
than the 64-bic authentication 71%*?* each ° SPF P«*et (other 
to detect data corruption *" ch ^k SUIn med in order 
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D.2 Simple password authentication 

^ Using this authentication type. . 64 _ bit Eield is configured 

:u^ r na:rth r is b c a o S n fi gu ^ ^lu'e" 5 SenC °H 3 PartiCUla ' — * 
authentication - field 9 This essentia Iv ^ 0SPF headv - S4 - bit 

checksummed in ^V^^^ 0 ^ 



be configured with its attached networks' passwords before it 

can participate in routing. However, simple password 
authentication is vulnerable 
to passive attacks currently- 

widespread in the Internet (see (Refl6)) . Anyone with physical 

access to the network can learn the password and compromise 

the 

security of the OSPF routing domain. 

D.3 Cryptographic authentication 

Using this authentication type, a shared secret key is 

configured in all routers attached to a common network/subnet. 
For each OSPF protocol packet, the key is used to 

generate/verify a "message digest* that is appended to the end 
of the OSPF packet. The message digest is a one-way function 

of 

the OSPF protocol packet and the secret key. Since the secret 
key is never sent over the network in the clear, protection is 
provided against passive attacks. 

The algorithms used to generate and verify the message digest 

are specified implicitly by the secret key. This specification 

completely defines the use of OSPF Cryptographic authentication 
when the MD5 algorithm is used. 

In addition, a non-decreasing sequence number is included in 
each OSPF protocol packet to protect against replay attacks. 
This provides long term protection; however, it is still 
possible to replay an OSPF packet until the sequence number 
changes. To implement this feature, each neighbor data structure 
contains a new field called the "cryptographic 
sequence number" . 

This field is initialized to zero, and is also set to zero 
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0 12 3 

0123 4567 8901 2345 6789 012 

3 4567 8901 

^_ + _ + - + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + 

I 0 | Key ID | Auth Data Len | 

+ - + - + - + - + - + - + - + - + - + - + -'+ - + - + ~ + - + - + - + - + - + - + - + - + + - + - + - + - + - + - + - + - + 
| Cryptographic sequence number - | 

4- -+- + - + - + - + - + - + + + ~ + - + - + + - + - + - + - + - + - + -»-- + --(-- + - + --(---(--+- + 

Figure 18: Usage of the Authentication field 
in the OSPF packet header when Cryptographic 
Authentication is employed 

whenever the neighbor's state transitions to "Down". Whenever an 
OSPF packet is accepted as authentic, the 
cryptographic sequence 

number is set to the received packet's sequence number . 



This specification does not provide a rollover procedure for the 
cryptographic sequence number. When the cryptographic sequence 
number that the router is sending hits the maximum value, the 
router should reset the cryptographic sequence number that it is 
sending back to 0. After this is done, the router's 

neighbors 

will reject the router's OSPF packets for a period of 
RouterDeadlnterval, and then the router will be forced to 

reestablish all adjacencies over the interface. However, it 

expected that many implementations will use "seconds since 
reboot" (or "seconds since I960", etc.) as the 

cryptographic 

sequence number. Such a choice will essentially prevent 
rollover, since the cryptographic sequence number field is 32 
bits in length. 

The OSPF Cryptographic authentication option does not provide 
confidentiality. 

When cryptographic authentication is used, the 64-bit 
Authentication field in the standard OSPF packet header is 
redefined as shown in Figure 18, The new field definitions are ' 
as . follows : 
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Key ID 

This field identifies the algorithm and secret key used to 
^ message digest appended to the OSPF packet Key 

Identifiers are unique per-interf ace (or equivalently, p er - 



the 



Auth Data Len 

The length in bytes of the message digest appended to 

OSPF packet. 

Cryptographic sequence number 

An unsigned 32-bit non-decreasing sequence number. Used to 
guard against replay attacks. 

«™T3""r ^r 5 " ^ nded t0 the ° SPF Packet- is not actually 
considered part • of the OSPF protocol packet: the message "digest 

no VS C i Uded in thS ° SPF heade r's packet length, although it 
is included m the packet's IP header length field. 

Each key -is identified by the combination of interface and Key 
ID. An interface may have multiple keys active at any one time 
This enables smooth transition from one key to another Each' 

has four time constants associated with it. These time constants 



of can be expressed in terms of a time-of-day clock, or in terms 
: e ~' S l0Cal Cl ° Ck «••"" ™*« of seconds since Ust 

KeyS tar tAccept 

_ The tim e that the router will st ar h 

that KX W1J -^ start accepting packets 

have been created with the given key. 

KeyStartGenerate 

The time that the router will <;t-*i-t- 

packet wlXi start usang the key for 

generation. 
KeyStopGenerate 

packet time thaC Che router stop using the key for 

generation . 

KeyStopAccep t 

have T^^^ P^ets that 

Standards Track [page 
° SPF V « si - ^ 



less 



teZ Kec^f!^ are 
replaces an eld. the KeyStartGen^ ?• "? flnlte - "hen a new key 
be less than or 1 'V? £ ° r ^ neW ke * mu « 

old equai to the KeyStopGenerate time of the 

key . 

Key storage should persist a rr n eo = 

cold, to avoid operational Issues In^T "Tit' Wa ™ ° r 
key associated with an interface expires Itil " ^ laSt 
revert to an unauthenticated condition »L " nacce P ta ble to 
. iast disrupt routing . T here f ore nd t h rrouter nd ^uTtSS^ * 

until Creat the as havxng an infinite lifetime 

the lifetime is extended, the kev i«= H 0 i- f ^ u 
management, or a new key is configured. * * " etWOrk 

D-4 Message generation 

After building the contents of an OSPF packet ,». 

D.4.1 Generating Null authentication 



set. to 



follows" 9 NUl1 aUthenticati °"- the packet is modified as 
U) The Autype field in the standard OSPF header is set to 

(2) The checksum field in the standard OSPF header is 

the standard IP checksum of the entire contents of fh» 
packet. starting with the OSPF packet he S r but 

excluding the S4-bit authentication field. This 
the C o n r. Ca } CulaCed as the "^it one's complement of 
nacJT COmplement sun > °f the 16-bit words in the 

Packet. excepting the authentication field If "he 
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packet's length is not. an integral number of 16-bit 
words, the packet is padded with a byte of zero K» f 
checksumming. zero before 

D.4.2 Generating Simple password authentication 

modifi:d n Is Sira fori^s" W ° rd - Che - ic "-n. the packet is 

(1) The Autype field in the standard OSPF header is set to 

set to <2) Checksum fie l° ^ the standard OSPF. header is 

the standard IP checksum of the entire contents of the 

excludina th» «f £"? Wlth the OSPF packec header but 
excluding the 64-bit authentication field. This 
checksum is calculated as the 16-hir , 
the one's complement sum of all t£ ,2 ^nvlement o£ 

packet excepting theluthLica ion field "if ^ he the 

wordf ^ le " 9C u 13 n ° C an inte ^l number of 16-bit 
words, the packet is padded with a byte of zero h»f 
checksumming. y r zero before 



l3 l * ThS 64 " bic authentication field in the OSPF ,- 

header is set to the 64-bit password (i e P 

interra'ce 3 ' 10 " ^ ^ haS been -"figur^ for the 
D.4.3 Generating Cryptographic authentication ' " 

When using Cryptographic authentication, there mav be 
multiple keys configured for the interface in ThL 
among the keys that are v 3 lirf f~ lncercace - In this case, 
that have KeyStartGenerate^ ^r^r" 1 ™ 
KeyStopGenerate) choose the one^wit^he most recent 



-generate time. Using this ^ ^ ^ ^ ^ 

Autype £ield in the standard ospp ^ is s ^ 
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~ , ;"■ — «■« 

calculated, but * e • 

» Du t is instead set to 0. 

(3) The Kev m / 

chosen key . s y (see Figure 18, is set to fc . 

Key ID. 1,6 

the message digest that will h. 

" eh ; i ™- - ~~ — ,. 

system's clock. lmple c °«nter. or be based on the 

(6) The message digest i= t-u 

s T pe a c- r "f d P L d tafeiST^ '« — • as " - 

^atenatLror^nr^roa^r^^ 15 ™» over the 

«d length fields produc, ' S f Cret key ' P«» 

digest (see (Refl7]) a hyte 

message 

(d) The MDS digest is • 

tended to the orig^"^^ OSPT ^ (i . e . . 

fa<.icecj . The digest is 



but counted in the OSPF packet's length field. 
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D-5 Message verification 

musc Whe " an ° SPF P«ck.t has been received on an interface, it 

^ a :2sS"£"S«s: tn'thrs^rvn 0 ^— is * 

interf-e"- ..^-^S^ ^^^U^PP^ 

S^^SLSfE specif^n" 

which fail authentication are discarded. " ""^ Packets 

D.5.1 Verifying Null authentication 

"PP h: a d n er NUl L s a t t b r tiCa V er°ified he rt T *» 
the 16-bit verified, rt must be set to 

i6 _ one's complement of the one's complement sum of all the 

field. W ° rdS ln Che 'P-ket. excepting the authentication 

bit Uf length is not an integral number of 16- 

chec^LgT^ " With 3 b ^te of zero before 

D.S. 2 Verifying simple password authentication 
When using Simple password authentication 

packet is authenticated as follows received OSPF 

verified. U> ^ checksum Ei *ia in the OSPP header must be 



one m s S c C ompleme e nt e S t um 0 of th a e il 16 th b e t ^ «^-nt of the 
B£. leng e th eP 1s g n^ar <» ^ 

(2 neader T l%t 64 be b ^ t q : a U 1 Ch co nC t h C e at 6 i 4° n bl f r ld *" ° SPF 

' authentication key) t t , PaSSWrd (ie - 

interface. haS been configured for the 
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D.5.3 Verifying Cryptographic authentication 

When using Cryptographic authentication, the received OSPF 
packet is authenticated as follows: ° SPF 



(1) 



Lv in t receiving interface's configured key having 

«~ir-? ^ o t0 that pitied in the received OSPF 

the key. 1S not va lid for reception (i e current Mm« <~ 

KeyStartAccept or current time >Ae y stopA h ^ 

OSPF packet is discarded. 



<2 i ^, I f thS c^cographic sequence number found in the ospp 
sl^r (See T gUre 18) 15 leSS than the cryptographic 
data S ^ enCe corded in the sending " neighbor's 

structure, the OSPF packet is discarded. 
^steps:^ 1 ^ ^ appended ^ssage digest in the following 

(a) The received digest is set aside. 

(b) o f n i: c ^ro.4 is 3 calculaced - as specified - st *p * 

compared. If ^ ^ calc ^"e d and received digests 

they do not match, the OSPF packet is discarded IF 

as'Lfh ^ tCH ' C ^ ° SPF P^o-l P^ket is accepted' 
as authentic, and the "cryptographic sequence 
number- ln the neighbor's data structures set . to 
header. Se<JUence number fou «d « the packet's OSPF 
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E. An algorithm for assigning Link State IDs 



„ « „ a. n „ euort . s ^ ^ However, „ ^..^ 

having the same address, yet diff^ \ Se P a «te LSAs for networks 

L hi LinTs e tate X £" ST ST*^ f~ - tting the host Mts 
^ o^e S . The only re -^ n -ones J^g™ i tS £" 
whe ne'er^* » — - sno Uld be _ d as sfcate ^ 

0SPp PO ^ple m enta h tronr imiZeS int -°P-abi lity wich 
predating RFC 1583. 

i..2j «.«»i^ b e 1 „- ». .„ „^ IM . 

Suppose that the router wishes to • ^ 
used to deterge the CSA • s Link ^ ^ " « 

an a!-' ° eterr " lne Whet her ^e router is already 

externaI- LSA w.th Link State in °"^»at ing 

an LSA the lnk State » equaX to NA ( in such 

router itself will K~ 1 • 

" -t. the Link Stace e iD a L set"" L f AS Adv «tisi ng Router, 

terminates. Otherwise, " S " e ^ al to NA and the algorithm 

e*is tlng ° btai " «" network rn.sk from the hod y of the aireadv 
AS-e.ternai-LSA. CaiX this mask m2 . There ^ ^ 

case, 15 lona " (i.e.. more specific) 

set th t - Pecifxc) than m2 Zn ^ 

Qr , ed [NA,NM1J wLh^Xx'^e^hosttits^r Ti e° ** 

. i i.e. , equal to NA 

■a. w hl ch°L ether With 911 Che ^ts that are noC set .„ 

network CNA.NMiPs broadcast address). 

S ihavi„ n g ger th L a Lk^ tat In T fc n iS — • change the existi„ g 

ne^ork [NA, NM1 J by ^ 2&?« -new 
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of a the n new h n ec :ork in The„ ^ ^ ** inse «-9 the cost 

~ WA?S°' with Link stated eSafto ^ „ 

together with the bits that are nor set L 

network [MA.NM2] - S broadcast address? Ue ' 

this™" ab ° Ve al ^ithm — that all masks are contiguous; 

ensures that when two networks havp n,« ^ 

more specific than the other The alcorithm^ address < ^ ^sk is 

also 31 ^ 5 Pr ° dUCeS UniqUe Li " k S ^te IDs . The above algorithm can 

^ be reworded as follows: When originating an AS-external-LSA, try 

use the network number as the Link State ID Tf 

be C °r^ubset eXamine tW ° " etW ° rks in confHct D - 0 ne f - 

n Umbe °r ° ther - F ° r thS le " Specific ~t-ork. use the network 

broad:ast n a k ddre S ss at Lstea a d d ( r EO e ^1^^^ 
_ -e most specific network-as^ginat^Irrtr^h^^^-^r 

to originate two LSAs at once. 

,1 U0.0.0 O 0^S5 A 25o n 2 t 55 t 0,r riginate ^"^nal-LSA for 

(a) A Link State ID of 10.0.0.0 is used. 

(2, (10.0.0°o: e 55 A 255 6 0.0?? tS ^ « AS-extemal-LSA for 

using a"' ^ < " . 0 . 0. 0 . 255 . 255 . 255 . 0 ) is reoriginated 

new Link State ID of 10.0.0.255. 

(b) A Link State ID of 10.0.0.0 is used f 
(10.0.0.0,255.255.0.0). ±sused for 



(3) 



IIO.O.^S^O^T" 16 ' t0 ° riginate » AS-external-LSA for 



Moy 

RFC 2328 



Standards Track 
OSPF Version 2 



[Page 23 7] 
April 1998 



(a) The LSA for [10.0.0 0 25S n m • 

using a ' ' ' 2bb ■ 255 0 • °3 ^ reoriginated 

new Link State ID of 10.0.255.255. 

(b) A Link State ID of 10.0.0.0 is used 
[10.0.0.0,255.0.0.01 - 

(c) The network [10.0 0 0 255 ice ft1 , 

Link State ID * * ' 5 * 255 ' 255 • 0] keeps its 

of 10.0.0.255. 
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F. Multiple interfaces to the same network/subnet 

There are at least two wave: k~ 
interfaces YS t0 su PP°rt multiple physical 

to the same IP subnet Both method 

implementations of RFC 15fli /= ^ * WlU inte roperate with 

two ~ JOJ (and of course this memo) . The 

methods are sketched hriofi,, 
that fetched briefly below. An assumption has been made 



than an OSPF issue) . . 
•Method 1: 

incerfaces'^endinr'" 6 ^ fU " Ctio " ali ^ over both 

other routers on the subnet win treat the £wo inter? ace" 

separate neighbors, since neighbors are X L ^ 

and NBMA networks) by their IP address identif ^ed (on broadcast 

Method 1 has the following disadvantages: 

adjacencies™ in — «=h. total nun.ber of neighbors and 

since l0SS directionality test on both interfaces, 

bidirectionality is based on Router ID. 
(3) You have to consider both interfaces together during 

Designated Router election. since if you ^ ^ 

Router U ^r e ° USly ^ ^ COnfuse the "e-breaker (which is 
Method 2: 

Run OSPF over only one interface (call i t- 

interface), but include !w it the primary 

interfaces in your Router- LSA the and secondary 

Method 2 has the following disadvantages: 

(1) You i OS e the bidirectionality test ™ 

interface. cy cest on the secondary 

(2> ~c^^ to promote the 
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G. Differences from RFC 2178 

This section documents th^ Hi fp„v 

2178. All differences are bafk^T" memo 
this, memo and of RFCs 2178 1583°°^^^^ Ir ^ — tations of 

J-^tiJ, and 1247 will interoperate . 

G.l Flooding. modifications 

Three changes have been made to t-h* fi„ bi- 

section 13. the fl oodmg procedure in 



The first change is to step 4 in Section 13. Now MaxAge LSAs 

are 

acknowledged and then discarded only when both a) there is no 

database copy of the LSA and b) none of router's neighbors 

are 

in states Exchange or Loading. In all other cases, the MaxAge 
LSA is processed like any other LSA. installing the 

LSA in the 

database and flooding it out the appropriate interfaces when 

the 

LSA is more recent than the database copy (Step 5 of Section 
13). This change also affects the contents of Table 19. 

The second change is to step 5a in Section 13. The 

MinLSArrival 

check is meant only for LSAs received during flooding, and 
should not be performed on those LSAs that the router itself 
originates . 

The third change is to step 8 in Section 13. Confusion between 
routers as to which LSA instance is more recent can cause a' 

disastrous amount of flooding in a link-state protocol (see 
[Ref26]) - OSPF guards against this problem in two ways: a) the 

LS age field is used like a TTL field in flooding, to 
eventually 

remove looping LSAs from the network (see Section 13.3), and b) 
routers refuse to accept LSA updates more frequently than once 

every MinLSArrival seconds (see Section 13). However, 

there is 

still one case in RFC 2178 where disagreements regarding which 
LSA is more recent can cause a lot of flooding traffic: 
responding to old LSAs by reflooding the database copy. For 
this reason. Step 8 of Section 13 has been amended to only 
respond with the database copy when that copy has not been 

sent 

in any Link State Update within the last MinLSArrival seconds. 
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G.2 Changes to external path preferences 

There is still the possibility of a routing loop in RFC 2178 
when both a) virtual links are in use and b) the same external 
route is being imported by multiple ASBRs, each of which is .in a 
separate area. To fix this problem, Section 16.4.1 has been 
revised. To choose the correct AS BR/ forwarding address, " intra- 
area paths through non-backbone areas are always preferred. 

However, intra-area paths through the backbone area (Area 0) and 
iriter-area paths are now of equal preference, and must be 
compared solely based on cost. . 

The reasoning behind this change is as follows. When virtual 
links are in use, an intra-area backbone path for one router 



can 
to 



turn into an inter-area path in a route r several hops closer 

the destination. Hence, intra-area backbone paths and inter-area 
paths must be of equal preference. We can safely compare thetr 
costs preferring the path with the smallest cost, -due to the 

calculations m Section 16.3. 

Thanks to Michael Briggs and Jeremy McCooey of the UNH 
Interoperability Lab for pointing out this problem. 

G.3 Incomplete resolution of virtual next hops 

°2L°L^\f" n f^° n ? ° f the calculation in Section 16.3 is to 



, . , ^-ux^uiaLluil in Section 16 3 e hr> 

determine the actual next hop,s, for those destinations ihose 
next hop was calculated as a virtual link in Sections 16.1 and 
ILL £ f f completion of - the calculation in Section 16.3. any 
paths calculated in Sections 16.1 and 16.2 that still have 
unresolved virtual next hops should be discarded 



G.4 Routing table lookup 



Inli fZr, ? 3 ^ e l00kUP al 9° rith «> ^ Section 11.1 has been 
table entrv " = Urrent P«ctice. The "best match- routing 

most- f • m° W 3lWayS selected to ^ the one providing the 
most spectre (longest) match. Suppose for exampli a rouctr is 
forwarding packets to the destination 192.9.1.1 A routina t^ble 

routLf" S l i\ U2i 3lWayS be a beCter m "ch IZl 9 tte 

routing table entry for 192.9/16. regardless of the routina 

paths 6 entrlSS ' Path -^ es - however that when muit pL 



?° y Standards Track . (Page 241) 

RF ° 2328 0SPF Ve "i°" 2 April 1998 

^Sectlons'lsT IS^'an^T J""' enCry ' the simulations 

and Dy mter -area, type 1 external 

type 2 external paths; see Section 11). 
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Security Considerations 



All OSPF protocol exchanges are authenticated. OSPF supports 

simple types of authentication; the type of authentication [n use 
can be configured on a per network segment basis. One of OSPF ' s 

authentication types, namely the Cryptographic authentication 

TanTf'i^ 1° ^ SeCUre a * ainst Passive attacks and provide 

significant protection against active attacks. When using the 
Cryptographic authentication option, each router appends a "messaae 
digest" to its transmitted OSPF packets. Receivers then use the 

OsV^l^ i: y authentic eiVed ^ * ^ ~* 

The quality of the security provided bv 

the Cryptographic 

authentication option depends completely on the strength of the 

message digest algorithm (MD5 is currently the 
only message digest 

the alg ° rithm specified), the strength of the key being used, and 

correct implementation of the security mechanism in all 
communicating OSPF implementations. it also requires that all 
parties maintain the secrecy of the shared secret key. 

Hn^hf 0S?F authenticat ion types provide confidentiality. Nor 

^ t do they protect against traffic analysis. Key management is also 

addressed by this memo. 

For more information, see Sections 8.1, 8.2, and Appendix D. 
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